Skip to main content
This lesson explains what happens under the hood when you run Terraform and how it translates your declarative HCL configuration into real infrastructure changes. Terraform is declarative: you describe the desired end state of your infrastructure using HCL (the HashiCorp Configuration Language). Terraform figures out what to create, change, or delete to reach that target state. For example, to request three Amazon EC2 instances and an Application Load Balancer, your configuration might look like this:
When you run terraform apply, Terraform turns that desired state into the necessary cloud API calls to create or modify real resources so the live environment matches your configuration. What about duplicate or repeated resources? In the example above, count = 3 ensures Terraform will create three instances and manage them as a single logical resource block.

​
How Terraform Knows What Currently Exists

Terraform tracks resources it manages using a state file (by default terraform.tfstate). This JSON file maps resource blocks from your configuration to actual cloud resource IDs and metadata. Example snippet from a state file:
When planning changes, Terraform compares three sources of truth:

​
What terraform plan Does

terraform plan previews changes by comparing the configuration, the saved state, and the live resources. It reports what will be created, changed, or destroyed without making any modifications.
Review the plan before running terraform apply so you can validate the intended changes.

​
Terraform Core vs Providers

Terraform Core orchestrates the overall process; providers perform the actual API calls. Terraform Core:
  • Reads your HCL configuration
  • Loads the saved state file
  • Queries provider plugins for live resource states
  • Builds a dependency graph of resources
  • Computes a plan with the right operation order (create/update/delete)
  • Invokes provider plugins in that order to enact changes
Provider plugins (for example, the AWS provider) implement the platform-specific logic and make the cloud API requests. Terraform Core does not call cloud APIs directly — it delegates to providers.
The image is a diagram explaining how Terraform Core interacts with AWS using a plugin to make API calls to cloud APIs, with mentions of dependency graphs and roles of interviewer and candidate.

​
Collaboration: Remote State and Locking

When multiple engineers run terraform apply against the same infrastructure, you must avoid conflicting updates. Terraform supports remote backends and state locking to prevent race conditions. Common remote backend patterns:
  • S3 backend + DynamoDB for locking (AWS)
  • Terraform Cloud / Terraform Enterprise
  • Other supported remote backends with lock support
If one user holds the lock during an apply, any concurrent apply attempts will be blocked until the lock is released. This prevents concurrent modifications that could corrupt the shared state or the real infrastructure.
Use a remote backend with locking (for example, S3 + DynamoDB or Terraform Cloud) when multiple engineers collaborate on the same infrastructure to avoid race conditions.
Do not manually edit terraform.tfstate. Manual edits can corrupt the state and lead to resource drift or accidental destruction. Use Terraform commands (taint, state subcommands, etc.) to manage state safely.

​
Handling Manual Changes (Drift)

If someone modifies a managed resource outside Terraform (for example, via a cloud console), Terraform will not automatically adopt those changes. On the next terraform plan or terraform apply, Terraform:
  • Queries the live resource via the provider,
  • Compares live state to the saved state and configuration,
  • Reports any drift in the plan,
  • And will update or recreate the resource during apply to match your configuration (if required).
This ensures the configuration remains the single source of truth.

​
Quick Reference: Command Purposes

​
Summary

  • Declare the desired end state in HCL.
  • Terraform stores resource mappings in terraform.tfstate.
  • terraform plan compares configuration, state, and live resources and shows a preview.
  • Terraform Core builds the dependency graph and orchestrates the order of operations.
  • Provider plugins perform the actual cloud API calls.
  • Use remote state and locking to safely collaborate across teams.
  • Drift (manual changes) is detected on the next plan/apply and corrected to match your configuration.
Links and references:

Watch Video