Introduction to Terraform

Why not just click infrastructure together? This module shows the difference between manual configuration and declarative infrastructure code: reproducible, version-controlled, reviewable. You compare Terraform with alternatives like Ansible, CloudFormation and Pulumi and understand when to use which tool. We also provide a factual overview of the current license situation (BSL) and the open-source fork OpenTofu.

Instead of lengthy theory, you write your first HCL file right away. You learn the building blocks of the HashiCorp Configuration Language: resource blocks, data blocks, attributes and references. Using the Local Provider, you create files on your system and run through the complete cycle from terraform init to terraform apply. By the end of this block, you read HCL like a familiar language.

Providers connect Terraform to the outside world: AWS, Azure, GCP or hundreds of other APIs. You configure your first cloud provider, pin versions in the required_providers block and understand the lifecycle of a terraform plan and terraform apply. Afterward, you know what happens under the hood with every command and why terraform plan before every apply is mandatory.

Hardcoded values make configurations inflexible. You work with input variables, define types (string, number, list, map, object) and set defaults and validation rules. With outputs you make results visible to other modules and the command line, and with locals you avoid repetition. At the end, you refactor your first configuration into a cleanly parameterised version.

Everything you learned comes together: you provision a dedicated VM with security group and elastic IP in the cloud. You use variables for region and instance type, outputs for the public IP, and the Terraform documentation as a reference. By the end of the day, your first code-defined infrastructure is running.

State is Terraform's memory: without it, Terraform doesn't know what exists. You configure a remote backend with S3 and DynamoDB (locking), enable versioning for rollbacks and understand why state files never belong in Git. Then you isolate state by environment and component so that a mistake in the staging network configuration doesn't endanger production.

Taking over existing infrastructure, renaming resources or removing them from state: in the past, you used imperative CLI commands for this. Today there is a better way. You work with the import block, the moved block and the removed block. These declarative operations are reviewable in pull requests, repeatable and self-documenting. You know the old CLI commands (terraform import, terraform state mv) as a fallback, but not as the standard.

Modules are the key to maintainable Terraform code. You build a custom module with input variables, outputs and internal logic. Then you consume modules from the Terraform Registry, pin versions with semantic versioning (~> 1.2.0) and auto-generate documentation with terraform-docs. By the end, you understand the principle of "small, reusable building blocks" and can apply it to your own projects.

How do you organise Terraform code when the project outgrows a single main.tf? You work with CLI workspaces for environment separation (dev, staging, prod), learn common file structure conventions (main.tf, variables.tf, outputs.tf, providers.tf) and apply DRY principles with modules. You also see how Terragrunt helps as an orchestration layer in larger setups.

You build a complete multi-tier infrastructure from reusable modules: VPC with public and private subnets, security groups and a VM in the private network. State is stored remotely, modules are versioned, and the structure follows the conventions from the previous block. At the end, you have a reference architecture you can carry over to your own projects.

HCL can do more than simple assignments. You work with for_each and count for dynamic resource creation, write dynamic blocks for repeated nested structures and use conditionals (condition ? true : false) for environment-dependent configuration. Built-in functions like lookup, merge, flatten and templatefile round out the picture. Afterward, you write HCL that adapts to changing requirements instead of rewriting it for every change.

Code without tests is a promise without proof. You write your first .tftest.hcl files with command = plan for unit tests and command = apply for integration tests. With provider mocking (since v1.7) you test modules without cloud credentials. Additionally, you use TFLint for static analysis and terraform validate as a baseline check. At the end, you have a test suite that catches errors before they cost money in the cloud.

Terraform state contains sensitive data, and sensitive = true alone does not protect it: the value still ends up in state. Since v1.10, ephemeral values exist: temporary credentials and tokens that never touch state. On top of that, write-only arguments (v1.11) provide resource attributes that are not persisted. You configure both mechanisms and supplement them with Checkov and Trivy for automated security scanning of your Terraform files.

In production teams, terraform apply does not run from a laptop. You integrate Terraform into a CI/CD pipeline with GitLab CI or GitHub Actions: plan as PR comment, apply after approval. You also learn the basics of HCP Terraform (formerly Terraform Cloud) as a managed backend and Atlantis as a self-hosted alternative. At the end, you have a clear picture of how Terraform workflows look in real teams.

Everything combined: you build a production-like infrastructure with custom modules, remote state backend, variables for environment separation and a test suite. On top, you write a CI pipeline skeleton that runs terraform plan automatically. The result is a Terraform project you take home as a template for your own work.