Cloud and infrastructure as code
Infrastructure as code with Terraform
Declaring infrastructure in code — providers, state, plans, modules, environments and the habits that keep apply safe.
Infrastructure as code (IaC) stores cloud resources as declarations in a repository. They are reviewed in pull requests, applied by a pipeline, and checked against reality. Terraform is the most common tool for this across AWS, GCP and Azure. OpenTofu is an open-source fork with the same workflow.
You write the desired state in HCL. Terraform compares it with a state file that records what it created, prints a plan, and applies the difference through cloud APIs after approval.
Concepts in reading order
| Step | Concept | What it answers |
|---|---|---|
| 1 | Why infrastructure as code | Why not click through the console? |
| 2 | Plan and apply | What will Terraform change, and how do you check it? |
| 3 | State and locking | How does Terraform know what it owns? |
| 4 | Modules and environments | How do you reuse standards and keep dev apart from prod? |
| 5 | Safe changes | How do you stop a bad apply from deleting a database? |
Read step 1 first. Steps 2 to 5 assume you know what a plan and a state file are.
Alternatives
| Tool | Style | When it fits |
|---|---|---|
| Terraform or OpenTofu | HCL, declarative, large provider ecosystem | The default for cloud and SaaS provisioning |
| Pulumi | TypeScript, Python or Go | Teams that want real abstractions, tests and IDE support |
| AWS CDK or CDKTF | Code that generates CloudFormation or Terraform | Deep in one cloud, and a preference for TypeScript |
| Crossplane | Kubernetes control plane for cloud resources | Platform teams that want kubectl apply as the only API |
OpenTofu follows Terraform's language and providers under an open license, so the HCL skills transfer. Do not rewrite working Terraform only for fashion.
Common mistakes
- Putting state in git. Rotate anything that leaked, and move to a remote backend the same day.
- Drifting out of band. Console changes must be imported or reverted, or the next apply surprises someone.
- Putting raw passwords in
.tfortfvarsfiles. Use secret references instead. See secrets and encryption. - Confusing workspaces. One wrong
selectcan aim an apply at the wrong environment.
In practice
Interviews often ask you to explain state and locking, the difference between an update and a replacement, how you would split prod and staging, and what prevent_destroy does. Being able to answer those with an example is the goal.
Key takeaways
- IaC makes infrastructure reviewable, repeatable and diffable.
- Read the plan for destroys and replacements before every apply.
- Use a remote backend with locking. Treat state changes as data migrations.
- Give each long-lived environment its own directory and state.
- Plan in CI, apply the saved plan, and guard databases.
Further learning
HashiCorp's tutorials are the best hands-on path after this overview.
Terraform tutorials (HashiCorp)Explore Terraform product documentation, tutorials, and examples.Tutorials | Terraform | HashiCorp Developer
OpenTofu documentationDocumentation | OpenTofuopentofu.org
Terraform style guideLearn recommended style conventions for Terraform configuration and workflows.Style Guide - Configuration Language | Terraform | HashiCorp DeveloperRelated
Cloud primitives on AWS and GCP
Regions, zones, compute, storage, managed databases and messaging, how the services map between AWS and GCP, and how to decide what to run yourself.
Continuous integration and the software supply chain
Fast, trustworthy pipelines - build, test, artifact, scan and sign - plus DORA metrics and supply-chain controls that keep trunk green.
Configuration, environments and feature flags
Twelve-factor config, environment parity, secrets injection, feature flags and the blast radius of a bad config push.