← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

📜 ClickOps vs infrastructure as code — lesson 01

⏮️ Before IaC

A person clicked through the console, sometimes with a wiki page of steps; each site came out a little different.

✅ फायदे

  • IaC: repeatable, reviewable, in git; 'No changes.' on a second run
  • ClickOps: fast for a first experiment, nothing to learn

❌ तोटे

  • IaC: a language, a state file and a workflow to learn
  • ClickOps: no record of why; slips multiply over fields and sites

👍 वापरा जेव्हा

  • IaC for anything that lives longer than a day or exists more than once
  • the console for exploring, reading and emergencies you write back

👎 दोनदा विचार करा जेव्हा

  • IaC for a one-hour throwaway experiment
  • ClickOps for production

📋 Update in place vs replace — lesson 03

⏮️ Before plans

Changes were made directly; nobody knew in advance whether a change would rebuild something.

✅ फायदे

  • update in place: same object, same id, usually no downtime
  • replace: a clean new object; create_before_destroy can avoid a gap

❌ तोटे

  • update: not every argument can change in place
  • replace: new id, data on the old object is gone

👍 वापरा जेव्हा

  • read every '# forces replacement' line before approving
  • prevent_destroy on things that hold data

👎 दोनदा विचार करा जेव्हा

  • replacing a database or bucket to change a name
  • -auto-approve on plans nobody read

🔁 count vs for_each — lesson 04

⏮️ Before loops

Copy-pasted resource blocks, one per locker.

✅ फायदे

  • count: simple for N identical things
  • for_each: stable addresses by key; removing one touches only that one

❌ तोटे

  • count: removing the middle item shifts every later address
  • for_each: keys must be known at plan time

👍 वापरा जेव्हा

  • for_each for anything with its own identity (users, buckets, disks)
  • count for 'on or off' (count = var.enabled ? 1 : 0)

👎 दोनदा विचार करा जेव्हा

  • count over a list of named things
  • for_each over values only known after apply

📒 Local state vs remote state with locking — lessons 05, 08

⏮️ Before remote state

terraform.tfstate on one laptop, sometimes committed to git.

✅ फायदे

  • local: zero setup for learning
  • remote + lock: one shared register, one writer at a time, versioned, encrypted

❌ तोटे

  • local: lost with the laptop; two people means two registers; secrets in files
  • remote: a bucket, access policies and locking to set up

👍 वापरा जेव्हा

  • remote state with locking and versioning for anything shared
  • tight read access — state holds secrets

👎 दोनदा विचार करा जेव्हा

  • state in git
  • locking turned off 'because it was stuck'

🏘️ Workspaces vs separate directories and accounts — lesson 10

⏮️ Before environments

One environment, tested in production.

✅ फायदे

  • workspaces: one config, quick to add an environment
  • directories + accounts: separate state, keys and CI roles

❌ तोटे

  • workspaces: same credentials; one wrong select hits prod
  • directories: some repetition; more folders to keep in step

👍 वापरा जेव्हा

  • workspaces for short-lived copies with the same access (feature stacks)
  • separate accounts and state for dev vs prod

👎 दोनदा विचार करा जेव्हा

  • CLI workspaces as the only wall around prod
  • copy-pasted folders without shared modules

🚀 Stored CI keys vs OIDC — lesson 12

⏮️ OIDC च्या आधी

A long-lived cloud access key in a CI secret, rotated rarely, shared by every job.

✅ फायदे

  • OIDC: short-lived credentials per job; nothing to leak or rotate
  • trust policy names the repo and branch or environment

❌ तोटे

  • OIDC: trust policies to write carefully (sub and aud)
  • stored keys: one leak = standing access until someone notices

👍 वापरा जेव्हा

  • OIDC with a read-only plan role and a main-only apply role
  • GitHub environments with reviewers for prod

👎 दोनदा विचार करा जेव्हा

  • a trust policy that matches repo:org/* or checks only the audience
  • the same role for plan and apply