English for Infrastructure as Code
Vocabulary and phrases for IaC work in English: module, state, plan/apply, idempotency, drift detection, resource lifecycle, and working with Terraform and Pulumi.
Infrastructure as Code (IaC) is the practice of managing infrastructure through machine-readable definition files rather than manual processes. Tools like Terraform, Pulumi, AWS CDK, and Ansible have created a shared vocabulary that crosses cloud providers and organisations.
This guide covers the core IaC terms with examples of how they are used in technical English — in code reviews, documentation, and architecture discussions.
Core IaC Concepts
Infrastructure as Code
Infrastructure as Code means defining infrastructure (servers, networks, databases, load balancers) in code — using configuration files or programming languages — so that it can be version-controlled, reviewed, tested, and deployed automatically.
“Before IaC, provisioning a new environment took two days of manual work. Now it’s a
terraform applythat completes in under twenty minutes.” “All infrastructure changes go through a pull request process, just like application code. No manual console changes allowed.”
Idempotency
An idempotent operation produces the same result regardless of how many times it is applied. IaC tools are designed to be idempotent — running apply multiple times with the same configuration should not create additional resources.
“The script is not idempotent — running it twice creates duplicate security group rules. We need to add existence checks.” “Terraform’s apply operation is idempotent: if the infrastructure already matches the desired state, it makes no changes.”
Terraform Workflow Vocabulary
Plan
terraform plan (or the equivalent in other tools) generates a preview of the changes that will be made to infrastructure without actually making them.
“Always run
planbeforeapplyin production — it gives you a human-readable preview of exactly what will change, be created, or be destroyed.” “The plan showed forty resources being destroyed and recreated. That triggered a conversation with the team before we proceeded.”
Apply
terraform apply executes the changes described in the plan and brings the infrastructure into the desired state.
“We run
applythrough the CI pipeline after the plan has been reviewed and approved in the pull request.” “Never runapplymanually in production — all applies go through the automated pipeline with a mandatory approval gate.”
Destroy
“We ran
terraform destroyon the staging environment to save costs over the weekend. The environment is rebuilt on Monday morning via the pipeline.”
State
State File
The state file (in Terraform: terraform.tfstate) is a record of what infrastructure Terraform believes exists. It maps resource definitions to real infrastructure objects.
“The state file is the source of truth for Terraform. If it gets out of sync with the real infrastructure, Terraform’s plan will be incorrect.” “We store the state file in a remote backend — an S3 bucket with DynamoDB locking — so the entire team shares the same state.”
State Locking
State locking prevents two concurrent operations from modifying infrastructure simultaneously and corrupting the state.
“The pipeline failed because another apply was already in progress and had acquired the state lock. Wait for it to complete before retrying.”
State Drift
Drift (or state drift) occurs when the actual infrastructure diverges from the state that the IaC tool believes exists — typically caused by manual changes made outside of the IaC workflow.
“The drift detection job runs nightly and reports any differences between the Terraform state and the actual AWS resource configurations. Any drift is treated as a bug.” “Someone manually added an ingress rule to the security group. Terraform detected the drift and flagged it as an unexpected configuration change.”
Modules and Organisation
Module
A module is a reusable, encapsulated unit of IaC code. Modules promote consistency and reduce duplication by allowing teams to share standard infrastructure patterns.
“We have a shared module for creating a standard ECS service — it creates the task definition, the service, the security groups, and the CloudWatch log group with sensible defaults.” “The networking module is maintained by the platform team and consumed by all product teams to ensure consistent VPC configuration.”
Root Module vs. Child Module
- The root module is the top-level directory where you run Terraform.
- A child module is any module called from the root or from another module.
“The root module calls three child modules: one for networking, one for the database, and one for the application layer.”
Resource Lifecycle
Resource Lifecycle
The resource lifecycle describes how a resource is created, updated, and destroyed. IaC tools manage lifecycle automatically based on configuration changes.
“Changing the instance type of an RDS database in Terraform triggers a replacement — the old database is destroyed and a new one is created. Make sure you understand the lifecycle implications before changing that field.”
create_before_destroy
This lifecycle configuration ensures a new resource is created before the old one is destroyed — useful for zero-downtime replacements.
“We added
create_before_destroyto the ALB target group so that the new group is registered before the old one is deregistered.”
prevent_destroy
“We added
prevent_destroy = trueto the production RDS instance. Now Terraform will refuse to destroy it, even if someone accidentally removes it from the configuration.”
Practical Phrases for IaC Work
- “All infrastructure changes must be made through IaC — no manual console changes.”
- “The plan looks clean — only the expected resources are changing. I’m approving the apply.”
- “There’s drift in the networking layer. Someone modified the security group manually.”
- “We extracted the database configuration into a reusable module shared across all environments.”
- “The state is stored remotely in S3. State locking is enabled via DynamoDB.”
- “This change will trigger a replacement. We need a maintenance window.”
IaC vocabulary has become standard across cloud engineering. Using these terms correctly allows you to contribute to IaC codebases, review infrastructure pull requests, and discuss cloud configuration changes with precision and confidence.