Ravindra BagaleCourses & study guides Track your progress

Guides

Terraform: Your First Plan and Apply

By , DevOps trainer LinkedIn Published: Last updated:

Read this guide in: English · मराठी · हिंदी

Why do we need Terraform? Because there is a real problem between developers and operations when cloud resources exist only as click history. Developers need a VPC, VM, or object storage for the app. Operations — the employee on the server / cloud side — clicks the console differently each week. Nobody remembers who created what. Terraform declares resources in .tf files: init → plan → apply → destroy when the lab ends. Always read the plan before you apply.

Friends, infrastructure as code means the cloud should match your files — not a mystery of console clicks.

Quick answer

Hold this vertical picture:

  1. Developer — needs cloud resources for the app.
  2. Operations — server/cloud-side person who must know what exists and why.
  3. The problem — click-ops; drift; “who created this?”; surprise bills.
  4. Terraform — code describes desired cloud; plan previews; apply changes reality.
  5. Pocket line: init → plan (read it) → apply → destroy labs.

Language: English · मराठी · हिंदी

Why do we need Terraform?

  1. Console clicks do not review well in Git.
  2. Operations on the cloud side needs a repeatable create/change/destroy story.
  3. Developers and operations share one definition of “what should exist.”

Need Terraform CLI, credentials for a cloud account you own, budget alerts. No invented prices — check your provider’s pricing pages. Optional: Ansible for software config vs Terraform for provision.

What does operations have to do with Terraform?

  1. Operations often owns accounts, IAM, and state backend later.
  2. Developers may write .tf files; both must read every plan.
  3. Do not commit secrets or terraform.tfstate casually.

What is the problem? Suppose we are…

Suppose we are building Instagram (like updates)

Suppose someone clicked a bucket and a VM in the console for a profile feature. Six months later nobody knows which clicks created production. A Friday change deletes the wrong resource.

Suppose we are working at Netflix and we are giving updates

Suppose frequent releases need the same infra shape in every environment. Click-ops cannot keep Netflix-scale environments identical.

Suppose you are working in Infosys on a client project

Suppose the client operations team asks: “Show the plan before you create anything in our account.” terraform plan is that conversation.

Terraform plan then apply Terraform reads .tf files, shows a plan of create/change/destroy, then apply makes infrastructure match the code. State tracks what exists. .tf files desired state HCL init providers plan + create ~ change - destroy apply Cloud API State file tracks real resources — read the plan before typing yes code → infrastructure Teaching flow only — not a fake AWS console screenshot

Terraform reads .tf files, shows a plan (+/~/-), then apply makes infrastructure match the code.

Terraform plan and apply Terminal-style teaching diagram of terraform init, plan and apply using a local_file example — not a cloud console.

Terminal-style teaching diagram: terraform init, plan, apply with a local lab example — not a fake AWS console.

How Terraform answers that same fight

mkdir tflab && cd tflab
terraform version

Write a minimal .tf for a provider/resource you are allowed to create (use current HashiCorp registry docs for the provider block — classroom may use a tiny cloud object or local_file for offline practice):

terraform {
  required_version = ">= 1.5.0"
}

# provider "…" { … }   # from official docs for your cloud
# resource "…" "example" { … }

terraform init
terraform plan
terraform apply      # type yes only if the plan is what you want
terraform destroy    # when the lab is finished

Add state to .gitignore for local labs. Prefer short-lived credentials / IAM roles — never paste expired tutorial keys.

Ravindra Bagale's Tip

Students run apply the moment init finishes. Habit: plan is mandatory reading. Apply without reading is clicking OK blindfolded on a client account. Destroy labs the same day when you can. Lakshat theva.

Common errors — story pain then fix

Pain from the stories Likely cause Fix
Provider credentials error Env / profile missing Configure auth per official docs
State locked Another apply / crashed lock Wait; follow team lock guidance — do not force unlock casually
Plan wants to replace everything Force-new attribute changed Read replace reasons carefully
Resource already exists Click-ops created same name Fresh prefix / import (advanced)
Accidental commit of tfstate State has sensitive data gitignore state; rotate if exposed

Learn it properly

Samajla ka? Why Terraform = stop click-ops mystery between developers and cloud/server-side operations; Instagram / Netflix / Infosys “suppose”; init → plan → apply → destroy. Read every plan.

Frequently asked questions

What is Terraform?

An infrastructure-as-code tool: you declare desired cloud resources in files, and Terraform calls provider APIs.

What is state?

Terraform records what it created in a state file so later plans know the real world.

Why plan before apply?

Plan is a dry run. Apply makes real changes — always read the plan.

Is local state OK for learning?

Yes for solo labs. Teams use remote state backends — learn that after the first apply.

Terraform vs Ansible?

Terraform shines at provisioning infrastructure. Ansible shines at configuring software on machines.

How do I avoid surprise bills?

Use tiny resources, set billing alerts in your cloud, and destroy labs when finished.