first plan/apply cycle
Create one `local_file` resource. Run `init`, `plan`, `apply`, then `destroy`. Capture only the summary lines (add/change/destroy). Timebox: 15 minutes.
DevOps & Tooling / Knowledge library
Terraform
infrastructure as code provisioning tool
Why learn Terraform?
Terraform lets teams define cloud and platform infrastructure as code, review changes before apply, and keep environments reproducible across dev/stage/prod.
Where it came from
Created by HashiCorp; first released in 2014. Built around declarative HCL and provider plugins. Became a default multi-cloud IaC tool through the late 2010s. From v1.5+ licensing shifted from MPL to BUSL. OpenTofu forked from pre-BUSL Terraform and continues as an open alternative.
- Created by HashiCorp; first released in 2014.
- Built around declarative HCL and provider plugins.
- Became a default multi-cloud IaC tool through the late 2010s.
- From v1.5+ licensing shifted from MPL to BUSL.
- OpenTofu forked from pre-BUSL Terraform and continues as an open alternative.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Create one `local_file` resource. Run `init`, `plan`, `apply`, then `destroy`. Capture only the summary lines (add/change/destroy). Timebox: 15 minutes.
- Build a module that creates a tagged AWS S3 bucket using `project` and `env` variables. Expose bucket name as output. Then call module from root. Timebox: 25 minutes.
- Use an S3 backend + DynamoDB lock table. Run `plan`, simulate a config rename, then preserve resource with a `moved` block. Explain why no recreate happened. Timebox: 35 minutes.
- After apply, change one cloud setting manually in console. Run `plan`, identify drift, and restore desired state via code. Submit drift lines only. Timebox: 20 minutes.
- Add a `check` block validating an output condition (for example, required tag exists). Show failing then passing plan after fix. Timebox: 20 minutes.
More ways to practice
variables + outputs mini-module
Build a module that creates a tagged AWS S3 bucket using `project` and `env` variables. Expose bucket name as output. Then call module from root. Timebox: 25 minutes.
team-safe state workflow
Use an S3 backend + DynamoDB lock table. Run `plan`, simulate a config rename, then preserve resource with a `moved` block. Explain why no recreate happened. Timebox: 35 minutes.
drift detection drill
After apply, change one cloud setting manually in console. Run `plan`, identify drift, and restore desired state via code. Submit drift lines only. Timebox: 20 minutes.
policy-minded review
Add a `check` block validating an output condition (for example, required tag exists). Show failing then passing plan after fix. Timebox: 20 minutes.
Documentation and sources
- Terraform documentation (developer.hashicorp.com)
- Terraform language reference (developer.hashicorp.com)
- Terraform CLI command reference (developer.hashicorp.com)
- Terraform Registry (registry.terraform.io)
- Terraform tutorials (developer.hashicorp.com)
Catalog research notes
- Config-driven import blocks reduce manual state-editing workflows.
- Recent 1.x releases expanded native module testing via `terraform test`.
- State refactoring safety improved with stronger move/import patterns.
- License change (BUSL for newer releases) led to the OpenTofu community fork.
Connect the ideas
Alternatives
Explore next
OpenTofuPulumiAWS CloudFormationAnsibleKubernetesCrossplaneGoogle Cloud Platform (GCP)GitHub ActionsGitLab CI/CDJenkinsPackerTrivyHashiCorp Vault
Real World Example
Automated Multi-Region Compliance Provisioning
A global financial services firm managing distributed cloud environments across multiple regulatory jurisdictions.
The business problem
Manual infrastructure provisioning leads to configuration drift, where security groups and encryption settings diverge across regions, creating audit failures and potential data exposure.
How this topic solves it
Terraform enables declarative infrastructure as code, allowing the firm to define a standardized security baseline in modules that are enforced consistently across all cloud regions regardless of the underlying provider.
- Define a standardized security module containing encrypted storage and firewall rules.
- Initialize the Terraform CLI to manage provider plugins and backend state storage.
- Create environment-specific configuration files that reference the central security module.
- Execute terraform plan to validate the proposed infrastructure changes against the baseline.
- Apply the configuration to synchronize the actual cloud environment with the desired state.
This diagram illustrates how Terraform modules enforce consistency across multiple cloud regions.
Central repository for standardized security templates
Engine for planning and applying infrastructure changes
Source of truth mapping code to cloud resources
Target environments for resource deployment
- Module Registry → imports templates → Terraform CLI
- Terraform CLI → reads and updates → State File
- Terraform CLI → provisions resources → Cloud Regions
Expected business outcome
The organization achieves a predictable, repeatable infrastructure footprint that simplifies compliance audits and eliminates manual configuration errors.
Limitations and checks
State file management becomes a critical point of failure; if the state file is corrupted or lost, Terraform loses the ability to map existing resources to the configuration, requiring manual reconciliation to regain control.