🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🚀 धडा 12 — CI/CD मधील IaC आणि संपूर्ण चित्र: PR वर plan, merge वर apply

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 · मागील: lesson-11-testing-policy

📦 या ब्रँचमध्ये काय आहे

धडे 01–11, आणि त्या सगळ्यांना एकत्र बांधणारा conveyor belt. आराखड्यातील प्रत्येक बदल म्हणजे एक pull request. CI त्यावर validate, plan, policy आणि cost चालवते आणि review साठी plan post करते. फक्त main मधील merge च apply करतो — आणि तो review झालेलाच plan apply करतो, नाहीतर थांबतो. CI थोडा वेळ टिकणाऱ्या OIDC token ने आपली ओळख सिद्ध करते, त्यामुळे कोणतीही cloud key कुठेही साठवलेली नसते. pipeline() हे iac/demo.py मध्ये आहे; oidc_token(), assume(), pr_pipeline() आणि merge_pipeline() हे iac/checks.py मध्ये; stale-plan तपासणी iac/engine.py मधील apply() मध्ये.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

आता कोणीही खिशात आराखडा घेऊन कंत्राटदाराकडे जात नाही. 📬 प्रत्येक नवा आराखडा कार्यालयाच्या ट्रेमध्ये (एक pull request) जातो. एक robot clerk 🤖 तो उचलतो, धडा 11 मधील चारही तपासनीस चालवतो, आणि कंत्राटदाराची यादी सूचना फलकावर लावतो: "हा plan एक library जोडतो: दर महिन्याला +₹1200." एक व्यक्ती ते वाचते आणि "मंजूर" म्हणते.

Robot कडे campus ची किल्ली नसते. फाटकावर तो एक दिवसाचा pass 🎫 दाखवतो ज्यावर लिहिलेले असते "मी campus-infra कार्यालयाचा robot आहे, main वर काम करतो". पहारेकरी pass तपासतो आणि त्याला एका तासासाठी आत सोडतो. Pull request वर काम करणाऱ्या robot ला असा pass मिळतो जो फक्त read-only दार उघडतो.

शुक्रवारी दोन plans मंजूर होतात: #42 (एक library) आणि #43 (एक gate). #43 आधी बांधला जातो. #42 ची पाळी येते तेव्हा robot पाहतो की #42 तपासल्यानंतर नोंदवही बदलली आहे. तो पुन्हा plan करतो — आणि नवा plan नवे gate पाडून टाकेल, कारण gate अस्तित्वात येण्याआधी #42 चा आराखडा लिहिला गेला होता. कोणीच हे मंजूर केले नव्हते, म्हणून robot थांबतो. दीपिका #42 ताज्या आराखड्याने update करते, नवा plan पुन्हा फक्त "एक library जोडा" असा होतो, आणि तो पुढे जातो.

🗺️ आकृती

flowchart LR
    pr["📬 pull request"] --> ci["🤖 CI (OIDC: campus-plan, read-only)<br/>validate · plan · policy · cost"]
    ci --> review["👀 plan posted, reviewed"]
    review --> merge["merge to main"]
    merge --> ap["🤖 CI (OIDC: campus-apply)<br/>lock · apply the saved plan"]
    ap -->|"state changed since plan"| stale["stale → re-plan"]
    stale -->|"same changes"| ok["apply"]
    stale -->|"different changes"| stop["stop, back to review"]
    ap --> reg["📒 remote register, locked"]

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/terraform/lesson-diagrams.html#l12

❓ काय

PR वर plan — प्रत्येक pull request init, validate, plan आणि तपासण्या चालवते, आणि plan comment म्हणून post करते. ते cloud साठी read-only असलेले credentials वापरते (plan तरीही state वाचतो आणि प्रत्येक object refresh करतो; state locking असेल तर त्याला lock file वर write access सुद्धा लागतो, किंवा तो -lock=false ने चालवला जातो).
Merge वर apply — फक्त main branch च, CI मध्ये, apply करू शकते. लोक laptops वरून apply करत नाहीत. त्यामुळे CI state ची एकमेव लिहिणारी बनते (धडा 08).
Saved plan — terraform plan -out=tfplan नेमक्या actions आणि ज्या state वरून तो बनवला ती state नोंदवतो. त्यानंतर state बदलली असेल तर terraform apply tfplan "Saved plan is stale" म्हणून नकार देतो.
OIDC federation — CI platform (GitHub Actions, GitLab CI, …) प्रत्येक job साठी signed, थोडा वेळ टिकणारा identity token देते. Cloud (AWS साठी: एक IAM OIDC identity provider + AssumeRoleWithWebIdentity) त्याचा issuer, audience आणि subject तपासते, आणि तात्पुरती credentials परत देते (AWS वर default म्हणून 1 तास). Leak किंवा rotate करण्यासारखे long-lived काहीच नसते.
Subject (sub) claim — job कोण आहे ते. GitHub ची उदाहरणे: repo:school/campus-infra:pull_request, repo:school/campus-infra:ref:refs/heads/main, आणि GitHub environment वापरणाऱ्या job साठी, repo:school/campus-infra:environment:prod. कोणते subjects role assume करू शकतात ते role ची trust policy ठरवते.
Orchestrators — Atlantis, HCP Terraform, Spacelift, env0 आणि इतर हा workflow तुमच्यासाठी चालवतात, प्रत्येक pull request नुसार locking आणि policy hooks सह.

🤔 का

कारण आधीच्या प्रत्येक धड्यात अपयशाचा एक असा प्रकार आहे जो माणूस दडपणाखाली विसरतो: न वाचलेला plan (03), leak झालेली state (05), दोन लिहिणारे (08), console मधील दुरुस्ती (09), चुकीचे workspace (10), गहाळ tag (11). Pipeline सुरक्षित मार्गालाच एकमेव मार्ग बनवते. OIDC मुळे CI मधली सर्वात जास्त चोरीला जाणारी गोष्ट नाहीशी होते — secret मधली long-lived cloud access key. आणि apply होणारा plan हाच review झालेला plan आहे हे तपासल्याने "मंजूर" आणि "पूर्ण" यांच्यातील फट बंद होते.

🔧 कसे (या repo मध्ये)

iac/checks.py मधील oidc_token(repo, event) GitHub Actions token मध्ये असणारे claims (iss, aud, sub) तयार करते. assume(role, token) ते ROLES शी shell-style matching ने तपासते, StringLike असलेल्या IAM trust policy सारखे. pr_pipeline() validate → plan → policy → cost चालवते आणि saved plan परत देते. merge_pipeline() lock घेते, saved plan apply करते, आणि StalePlan आला तर पुन्हा plan करते आणि नवा plan तेच बदल करत असेल तरच apply करते. iac/engine.py मधील apply() backend चा serial किंवा lineage plan पेक्षा वेगळा असेल तेव्हा StalePlan उठवते.

🧪 करून पाहा

python3 iac/demo.py pipeline
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from checks import oidc_token, assume
for event, ref in (("push", "refs/heads/main"), ("push", "refs/heads/feature-gym"), ("pull_request", None)):
    t = oidc_token("school/campus-infra", event, ref)
    print(f"{t['sub']:<52} → {assume('campus-apply', t)}")
t = oidc_token("someone/other-repo", "push")
print(f"{t['sub']:<52} → {assume('campus-plan', t)}")
EOF
python3 iac/test_iac.py

✅ तपासा — तुम्हाला काय दिसायला हवे

pipeline हे छापते:

      → campus-apply: AccessDenied — sub 'repo:school/campus-infra:pull_request' does not match
   PR #42: plan (state serial 1) → Plan: 1 to add, 0 to change, 0 to destroy.
   PR #42: cost → ₹1200/month → ₹2400/month (+1200)
   merge #43: Apply complete! Resources: 1 added, 0 changed, 0 destroyed. (state serial 2)
   merge #42: Saved plan is stale: the state was changed by another operation after the plan was created.
   merge #42: re-plan (state serial 2) → Plan: 1 to add, 0 to change, 1 to destroy.
   merge #42: the new plan is NOT the plan that was reviewed → stop, nothing applied
   PR #42 (rebased on main): plan (state serial 2) → Plan: 1 to add, 0 to change, 0 to destroy.
   merge #42: Apply complete! Resources: 1 added, 0 changed, 0 destroyed. (state serial 3)
── main = campus: register serial 3 · 3 resources · campus 3 objects

तुमचा snippet हे छापतो:

repo:school/campus-infra:ref:refs/heads/main         → campus-apply: granted, read-write (apply), session 3600 s
repo:school/campus-infra:ref:refs/heads/feature-gym  → campus-apply: AccessDenied — sub 'repo:school/campus-infra:ref:refs/heads/feature-gym' does not match
repo:school/campus-infra:pull_request                → campus-apply: AccessDenied — sub 'repo:school/campus-infra:pull_request' does not match
repo:someone/other-repo:ref:refs/heads/main          → campus-plan: AccessDenied — sub 'repo:someone/other-repo:ref:refs/heads/main' does not match

Tests 12/12 passed ने संपतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

फक्त योग्य repository ची main च apply role assume करू शकली; feature branch, pull request आणि दुसरी repository करू शकली नाही. दोन मंजूर PRs मध्ये शर्यत लागली: दुसऱ्याचा saved plan stale झाला होता, आणि त्याचा ताजा plan पहिल्याचे gate destroy करणार होता — म्हणून कोणीही review न केलेले काहीतरी apply करण्याऐवजी pipeline थांबली. Rebase नंतर plan पुन्हा review झालेलाच झाला, आणि main, नोंदवही (3 resources, serial 3) आणि campus (3 objects) या सगळ्यांचे एकमत आहे.

⚠️ नेहमीच्या चुका

CI secrets मध्ये "सध्यापुरती" ठेवलेली long-lived AWS_ACCESS_KEY_ID
sub = repo:school/* किंवा फक्त aud तपासणारी trust policy — org मधली कोणतीही branch, कोणतीही repo ती assume करू शकते
apply job सारखाच read-write role वापरणारा plan job
merge च्या वेळी पुन्हा plan करणे आणि review झालेल्या plan शी तुलना न करता जे निघेल ते apply करणे
"आणीबाणीसाठी" console आणि laptop applies अजूनही चालू ठेवणे, आणि ते परत लिहिण्याचा कोणताही नियम नसणे (धडा 09)

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — AWS कडे OIDC सह GitHub Actions. Apply job prod नावाचे GitHub environment वापरतो (ज्याला reviewer आवश्यक करता येतो), म्हणून त्याचा sub repo:school/campus-infra:environment:prod असतो:

name: terraform
on:
  pull_request:
  push:
    branches: [main]
permissions:
  id-token: write          # allow the job to request an OIDC token
  contents: read
  pull-requests: write     # to comment the plan
jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/campus-plan
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform validate
      - run: terraform plan -input=false -out=tfplan
  apply:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: prod
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/campus-apply
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - run: terraform apply -input=false tfplan

Apply role ची trust policy:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:school/campus-infra:environment:prod"
    }
  }
}

हा workflow merge वर पुन्हा plan करतो आणि तो plan apply करतो. review झालेला plan नेमका apply करायचा असेल, तर PR चा tfplan artifact म्हणून ठेवा आणि तोच apply करा (stale असेल तर Terraform तो नाकारते), किंवा merge आधीच pull request मधून apply करणारे Atlantis सारखे tool वापरा. CI/CD शाळा आणि IAM शाळा pipelines आणि trust policies बद्दल अधिक खोलात जातात.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: तुमच्या CI secrets मध्ये cloud access keys शोधा. प्रत्येक key च्या जागी असा OIDC role ठेवा ज्याची trust policy एक repository आणि एक branch किंवा environment नमूद करते — आणि plan job ला read-only role द्या.

🎓 आराखडा पूर्ण झाला

Clicks पुन्हा करता येत नाहीत, आराखडा करता येतो → provider चे schema सांगते की आराखड्यात काय लिहिता येते → plan फक्त फरक बांधतो, आणि ForceNew म्हणजे पुनर्बांधणी → variables आणि for_each मुळे एक design अनेक खोल्यांना बसते → नोंदवही प्रत्येक address एका खऱ्या object शी जोडते, secrets सकट → graph कामाचा क्रम ठरवतो आणि ते parallel चालवतो → modules एका pattern ला एका review झालेल्या गोष्टीत बदलतात → एक remote नोंदवही, एका वेळी एकच लिहिणारा → refresh drift शोधतो, import आणि moved नोंदवही प्रामाणिक ठेवतात → environments ना स्वतःची state आणि स्वतःच्या keys मिळतात → कंत्राटदाराच्या आधी तपासनीस plan वाचतात → आणि pipeline review झालेल्या plan लाच आत जाण्याचा एकमेव मार्ग बनवते. तुम्ही फक्त Terraform शिकला नाहीत — आता तुम्ही कोणताही cloud पाहून योग्य प्रश्न विचारू शकता: त्याचा आराखडा कुठे आहे, त्याची नोंदवही कुठे आहे, apply कोण करू शकते, आणि त्यांच्या बाहेर काय बदलले? 📜👷🎓

⏭️ पुढे

इतर शाळा. AWS शाळा हा campus आहे जो हे आराखडे सहसा बांधतात; CI/CD शाळा conveyor belt चालवते; IAM शाळा trust policies लिहिते; Argo CD शाळा तीच "desired state in git" कल्पना Kubernetes मध्ये लागू करते; आणि School portal मध्ये बाकी सगळे आहे.

git checkout main
python3 iac/demo.py     # one last run, for fun

🚀 Lesson 12 — IaC in CI/CD & the whole picture: plan on the PR, apply on merge

📍 You are here: Lesson 12 of 12 · Previous: lesson-11-testing-policy

📦 What's in this branch

Lessons 01–11, plus the conveyor belt that ties them together. Every change to the plans is a pull request. CI runs validate, plan, policy and cost on it and posts the plan for review. Only a merge to main applies — and it applies the plan that was reviewed, or stops. CI proves who it is with a short-lived OIDC token, so no cloud key is stored anywhere. pipeline() in iac/demo.py; oidc_token(), assume(), pr_pipeline() and merge_pipeline() in iac/checks.py; the stale-plan check in apply() in iac/engine.py.

🧒 Explain like I'm 5

Nobody walks up to the contractor with plans in their pocket any more. 📬 Every new plan goes into the office tray (a pull request). A robot clerk 🤖 picks it up, runs all four inspectors from lesson 11, and pins the contractor's list on the notice board: "This plan adds a library: +₹1200 a month." A person reads it and says "approved".

The robot doesn't carry a key to the campus. At the gate it shows a day pass 🎫 that says "I am the robot of the campus-infra office, working on main". The guard checks the pass and lets it in for one hour. A robot working on a pull request gets a pass that opens only the read-only door.

On Friday two plans are approved: #42 (a library) and #43 (a gate). #43 is built first. When #42's turn comes, the robot sees that the register has changed since #42 was checked. It plans again — and the new plan would knock down the new gate, because #42's plans were written before the gate existed. That is not what anyone approved, so the robot stops. Dipika updates #42 with the latest plans, the new plan is just "add a library" again, and it goes through.

🗺️ Diagram

flowchart LR
    pr["📬 pull request"] --> ci["🤖 CI (OIDC: campus-plan, read-only)<br/>validate · plan · policy · cost"]
    ci --> review["👀 plan posted, reviewed"]
    review --> merge["merge to main"]
    merge --> ap["🤖 CI (OIDC: campus-apply)<br/>lock · apply the saved plan"]
    ap -->|"state changed since plan"| stale["stale → re-plan"]
    stale -->|"same changes"| ok["apply"]
    stale -->|"different changes"| stop["stop, back to review"]
    ap --> reg["📒 remote register, locked"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/terraform/lesson-diagrams.html#l12

❓ What

Plan on PR — every pull request runs init, validate, plan and the checks, and posts the plan as a comment. It uses credentials that are read-only for the cloud (a plan still reads the state and refreshes every object; with state locking it also needs write access to the lock file, or runs with -lock=false).
Apply on merge — only the main branch, in CI, can apply. People do not apply from laptops. This makes CI the only writer of the state (lesson 08).
Saved plan — terraform plan -out=tfplan records the exact actions and the state it was made against. terraform apply tfplan refuses with "Saved plan is stale" if the state changed since.
OIDC federation — the CI platform (GitHub Actions, GitLab CI, …) issues a signed, short-lived identity token for each job. The cloud (for AWS: an IAM OIDC identity provider + AssumeRoleWithWebIdentity) checks its issuer, audience and subject, and returns temporary credentials (1 hour by default on AWS). Nothing long-lived to leak or rotate.
Subject (sub) claim — who the job is. GitHub examples: repo:school/campus-infra:pull_request, repo:school/campus-infra:ref:refs/heads/main, and, for a job that uses a GitHub environment, repo:school/campus-infra:environment:prod. The role's trust policy decides which subjects may assume it.
Orchestrators — Atlantis, HCP Terraform, Spacelift, env0 and others run this workflow for you, with locking per pull request and policy hooks.

🤔 Why

Because every earlier lesson has a failure mode that a human forgets under pressure: the unread plan (03), the leaked state (05), two writers (08), a console fix (09), the wrong workspace (10), the missing tag (11). A pipeline makes the safe path the only path. OIDC removes the most-stolen thing in CI — a long-lived cloud access key in a secret. And checking that the applied plan is the reviewed plan closes the gap between "approved" and "done".

🔧 How (in this repo)

oidc_token(repo, event) in iac/checks.py builds the claims a GitHub Actions token carries (iss, aud, sub). assume(role, token) checks them against ROLES with shell-style matching, like an IAM trust policy with StringLike. pr_pipeline() runs validate → plan → policy → cost and returns the saved plan. merge_pipeline() takes the lock, applies the saved plan, and on StalePlan plans again and applies only if the new plan makes the same changes. apply() in iac/engine.py raises StalePlan when the backend's serial or lineage differs from the plan's.

🧪 Try it

python3 iac/demo.py pipeline
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from checks import oidc_token, assume
for event, ref in (("push", "refs/heads/main"), ("push", "refs/heads/feature-gym"), ("pull_request", None)):
    t = oidc_token("school/campus-infra", event, ref)
    print(f"{t['sub']:<52} → {assume('campus-apply', t)}")
t = oidc_token("someone/other-repo", "push")
print(f"{t['sub']:<52} → {assume('campus-plan', t)}")
EOF
python3 iac/test_iac.py

✅ Verify — what you should see

pipeline prints:

      → campus-apply: AccessDenied — sub 'repo:school/campus-infra:pull_request' does not match
   PR #42: plan (state serial 1) → Plan: 1 to add, 0 to change, 0 to destroy.
   PR #42: cost → ₹1200/month → ₹2400/month (+1200)
   merge #43: Apply complete! Resources: 1 added, 0 changed, 0 destroyed. (state serial 2)
   merge #42: Saved plan is stale: the state was changed by another operation after the plan was created.
   merge #42: re-plan (state serial 2) → Plan: 1 to add, 0 to change, 1 to destroy.
   merge #42: the new plan is NOT the plan that was reviewed → stop, nothing applied
   PR #42 (rebased on main): plan (state serial 2) → Plan: 1 to add, 0 to change, 0 to destroy.
   merge #42: Apply complete! Resources: 1 added, 0 changed, 0 destroyed. (state serial 3)
── main = campus: register serial 3 · 3 resources · campus 3 objects

Your snippet prints:

repo:school/campus-infra:ref:refs/heads/main         → campus-apply: granted, read-write (apply), session 3600 s
repo:school/campus-infra:ref:refs/heads/feature-gym  → campus-apply: AccessDenied — sub 'repo:school/campus-infra:ref:refs/heads/feature-gym' does not match
repo:school/campus-infra:pull_request                → campus-apply: AccessDenied — sub 'repo:school/campus-infra:pull_request' does not match
repo:someone/other-repo:ref:refs/heads/main          → campus-plan: AccessDenied — sub 'repo:someone/other-repo:ref:refs/heads/main' does not match

The tests end with 12/12 passed.

🏁 What you just proved

Only main of the right repository could assume the apply role; a feature branch, a pull request and another repository could not. Two approved PRs raced: the second one's saved plan was stale, and its fresh plan would have destroyed the first one's gate — so the pipeline stopped instead of applying something nobody reviewed. After the rebase, the plan was the reviewed one again, and main, the register (3 resources, serial 3) and the campus (3 objects) all agree.

⚠️ Common mistakes

a long-lived AWS_ACCESS_KEY_ID in CI secrets "for now"
a trust policy with sub = repo:school/* or only an aud check — any branch, any repo in the org can assume it
the plan job using the same read-write role as the apply job
re-planning at merge time and applying whatever comes out, with no comparison to the reviewed plan
still allowing console and laptop applies "for emergencies" with no rule to write them back (lesson 09)

🏭 In production

On a real account — GitHub Actions with OIDC to AWS. The apply job uses a GitHub environment called prod (which can require a reviewer), so its sub is repo:school/campus-infra:environment:prod:

name: terraform
on:
  pull_request:
  push:
    branches: [main]
permissions:
  id-token: write          # allow the job to request an OIDC token
  contents: read
  pull-requests: write     # to comment the plan
jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/campus-plan
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform validate
      - run: terraform plan -input=false -out=tfplan
  apply:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: prod
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/campus-apply
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - run: terraform apply -input=false tfplan

The apply role's trust policy:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:school/campus-infra:environment:prod"
    }
  }
}

This workflow plans again on merge and applies that plan. To apply exactly the reviewed plan, keep the PR's tfplan as an artifact and apply it (Terraform refuses it if stale), or use a tool such as Atlantis that applies from the pull request before merge. The CI/CD school and the IAM school go deeper on pipelines and trust policies.

🏭 Why this matters in production: search your CI secrets for cloud access keys. Replace each with an OIDC role whose trust policy names one repository and one branch or environment — and give the plan job a read-only role.

🎓 The plans are complete

Clicks cannot be repeated, plans can → a provider's schema says what the plans may say → the plan builds only the difference, and ForceNew means rebuild → variables and for_each make one design fit many rooms → the register binds every address to a real object, secrets included → the graph orders the work and runs it in parallel → modules turn a pattern into one reviewed thing → one remote register, one writer at a time → refresh finds drift, import and moved keep the register honest → environments get their own state and their own keys → inspectors read the plan before the contractor does → and the pipeline makes the reviewed plan the only way in. You didn't just learn Terraform — you can look at any cloud and ask the right questions: where are its plans, where is its register, who may apply, and what changed outside them? 📜👷🎓

⏭️ Next

The other schools. The AWS school is the campus these plans usually build; the CI/CD school runs the conveyor belt; the IAM school writes the trust policies; the Argo CD school applies the same "desired state in git" idea inside Kubernetes; the School portal has the rest.

git checkout main
python3 iac/demo.py     # one last run, for fun

← Previoustesting policy Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-iac-cicd branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.