Introduction to Terraform

Infrastructure as code describes infrastructure declaratively in versioned configuration. You compare Terraform with Ansible, CloudFormation, and Pulumi and distinguish provisioning, configuration management, and platform-specific approaches by typical boundaries. The comparison includes OpenTofu and different governance and licensing models without turning them into a general product recommendation.

A Terraform configuration combines blocks, arguments, and expressions in HCL. You examine resource and data blocks, attributes, and references and use the local provider for a self-contained first example. You then run terraform init, plan, and apply and trace the files and state Terraform creates along the way.

Providers translate configuration into API calls for the connected platform. You define required_providers, set explicit version constraints, and read the dependency lock file. You then compare plan and apply as separate steps and treat a plan as a change preview that must be checked again before the actual operation.

Input variables make configurations adaptable but require clear types and boundaries. You define scalar and structured types, defaults, and validation rules and use outputs for selected results and module handovers. With locals, you group derived values and refactor the existing configuration without expanding its interfaces unnecessarily.

The DevNinjas Dojo, our cloud learning environment, connects providers, variables and references through a cloud scenario. You model a VM, a security group and a public or elastic IP and use outputs for selected connection data. The Terraform documentation and plan output support the work but do not replace informed approval.

State maps configured resources to their remote objects and can contain sensitive data. You configure an S3 backend, enable versioning, and compare current lock-file locking through use_lockfile with the deprecated DynamoDB-based mechanism. You then separate state by environments and components and examine access permissions, recovery, and the limits of that isolation.

Existing resources, changed addresses, and deliberate removals require transparent state operations. You work with import, moved, and removed blocks and first examine their effect in a plan. You assess imperative commands such as terraform import and terraform state mv as focused tools rather than defaults for every change.

Modules encapsulate resources behind defined inputs and outputs. You develop a custom module, separate internal logic from its public interface, and consume a component from the Terraform Registry. Version constraints and terraform-docs then help keep dependencies and documentation transparent but do not replace compatibility testing.

Larger configurations need visible responsibilities rather than merely more files. You organise main.tf, variables.tf, outputs.tf, and providers.tf, apply modules for reuse, and examine CLI workspaces. You distinguish workspaces from separate backends, permissions, and credentials for complex deployments and consider Terragrunt as a possible orchestration approach.

A coherent scenario connects module boundaries, remote state, and networking concepts. You design a VPC with public and private subnets, security groups, and a VM in the private network and distribute responsibilities across modules. In the lab, you inspect interfaces, versions, and dependencies without presenting them as a transferable reference architecture.

Expressions control how Terraform derives values and describes repeated resources. You compare for_each and count, generate nested blocks dynamically, and formulate conditional expressions. With lookup, merge, flatten, and templatefile, you process data structures and discuss when added dynamism makes a configuration clearer or harder to maintain.

Terraform tests describe runs and assertions in .tftest.hcl files. In this process, you compare plan and apply runs and use provider mocking for suitable module tests in Terraform 1.7 and later. terraform validate and TFLint complement these tests with syntax, schema, and static checks but cannot cover every runtime effect.

Values marked as sensitive are redacted from output but can still remain in state. You examine ephemeral values and ephemeral resources available in Terraform 1.10 and later, write-only arguments available in 1.11 and later, and account for which types or arguments the relevant provider supports. You also use Checkov and Trivy for configuration scans and treat findings as review signals rather than automatic approvals.

CI can provide repeatable checks but requires deliberate permission and approval boundaries. You outline a workflow with GitLab CI or GitHub Actions, publish plan output for review, and separate approved apply steps. HCP Terraform and Atlantis serve as comparison points for execution, state, and collaboration rather than as a universal target architecture.

Finally, you connect modules, remote state, environment variables, tests, and a CI-supported plan in one scenario. You place the provider, plan, and pipeline workflow in context and examine which decisions remain project-specific. The exercise supports transfer of the concepts and is not a production-ready system or binding operating model.