AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 67“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Project 4: Terraform Multi-Account Landing Zone

TechLearningPro outgrew a single shared AWS account: developers, CI, production workloads, and security tooling collided on IAM and blast radius. This portfolio project delivers a

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Project 4: Terraform Multi-Account Landing Zone

AWS Cloud & DevOps Engineering · Lesson 67 · Production Projects and Interview

Lesson Overview

TechLearningPro outgrew a single shared AWS account: developers, CI, production workloads, and security tooling collided on IAM and blast radius. This portfolio project delivers a Terraform-driven multi-account landing zone—Organizational Units (OUs), account vending patterns, baseline networking hooks, IAM Identity Center / role assumption patterns, guardrail intent (SCP concepts), remote state, modular IaC, and policy-as-code checks. You will not invent Control Tower APIs; you will design and, where your sandbox allows, implement a minimal but credible multi-account skeleton that future Projects 1–3 and 5 can attach to.

Continuity: Organizations and Control Tower concepts (48), cross-account access (49), Terraform (30–31), policy as code (35), WAR/ADRs (58). Tag Project=tlp-lesson67. Multi-account labs can incur organizational charges and sticky resources—budget, plan destroy, and prefer design-plus-partial-apply if you lack org admin.

Learning Objectives

State the business problem of single-account blast radius for TechLearningPro.
Define FRs/NFRs for isolation, auditability, and account provisioning speed.
Sketch OU topology: Security, Shared, Sandbox, Workloads (Dev/Test/Prod).
Explain Terraform remote state, state locking, and per-account state boundaries.
Design module layout for account baseline (CloudTrail, Config, budgets, tags).
Document IAM cross-account role assumption patterns without inventing APIs.
Describe SCP intent (deny leave org, deny disable CloudTrail) citing official SCP examples.
Integrate terraform plan with policy checks (OPA/Conftest, Checkov, or tfsec—verify current tool CLIs).
Separate network hub ideas (TGW from lesson 52) as a later module ADR.
Provide operating guidance: who applies what, break-glass, drift.
Run failure tests: denied SCP-like policy; broken assume-role.
Estimate cost (accounts, CloudTrail, Config, NAT in shared) illustratively.
Produce deploy/destroy guidance that does not casually delete organization roots.
Package portfolio: diagrams, modules, plan outputs, ADRs.
Compare Control Tower vs DIY Terraform landing zone trade-offs honestly.
Define tagging policy and budget baselines per account.
Explain identity federation via IAM Identity Center conceptually.
Connect workload accounts to Projects 64–66 placement.
Write ADRs for state strategy and for SCP severity.
Prepare interview answers on multi-account strategy.

Prerequisites

Lessons 30–31, 35, 48–49; optional 52 for networking hub.
Prefer an AWS Organizations management account sandbox; if unavailable, deliver architecture + local modules + simulated plan and document constraints.
Never experiment with SCPs in production management accounts.

Detailed Core Concepts

Business problem

A contractor with broad IAM in a single account can delete production data, disable logging, or create expensive GPU instances. TechLearningPro needs account-level isolation, centralized security tooling, and Terraform that can recreate baselines—not clickops folklore.

Functional requirements

Documented OU and account map.
Terraform modules for baseline security logging and budgets.
Remote state backend design (S3 + DynamoDB lock, or equivalent current pattern).
Cross-account admin/devops role pattern documented.
Policy checks in CI for risky Terraform.
Operating runbook for vending a new workload account (manual or automated).

Non-functional requirements

Least privilege; prevent accidental org deletion; auditable changes; reproducible plans; cost visibility per account; safe cleanup of lab-created resources without destroying unmanaged production.

Service selection rationale

Piece	Choice	Why
Org structure	AWS Organizations	Native multi-account
Guardrails	SCPs (+ optional Control Tower)	Preventive controls
IaC	Terraform modules	Multi-account, multi-provider familiarity
State	Remote per OU/account stack	Blast radius for state corruption
Identity	IAM Identity Center / assume role	Human access path
Policy CI	Checkov/tfsec/OPA	Shift-left

Control Tower accelerates account factory and baselines; DIY Terraform maximizes flexibility. ADR-6701 records the choice for TechLearningPro labs: Terraform modules + Organizations APIs you verify in docs, with Control Tower as optional accelerator—not both fighting.

Repo structure

text
tlp-landing-zone/
  modules/
    account_baseline/
    iam_assume_roles/
    cloudtrail_org/      # only if org trail supported in your design
    budgets/
  stacks/
    management/
    security/
    shared-network/
    workload-dev/
  policies/              # OPA/Conftest or Checkov config
  docs/adr/
  docs/runbooks/account-vending.md
  README.md

IaC approach

One state per stack; CI role can plan broadly but apply narrowly. Use terraform_remote_state or SSM parameters carefully for cross-stack outputs. Version modules with tags. Never commit .tfstate or credentials.

Security

Management account is sacred—limit human use. Security Tooling account owns GuardDuty/Security Hub aggregation concepts (lesson 43). SCPs deny risky actions in sandbox/prod differently. Break-glass role with MFA and logging.

CI/CD

fmt → validate → plan → policy scan → manual approval → apply for management-adjacent stacks. Workload stacks may auto-apply in sandbox only.

Monitoring

CloudTrail organization trail (confirm setup in current docs); Config recorders; budget alerts per account; drift detection via scheduled plans.

Cost

Accounts themselves are free at creation historically, but baselines (Config, CloudTrail to S3, GuardDuty) are not. Shared NAT and TGW dominate. Destroy lab baselines carefully; do not delete organization as “cleanup.”

Architecture and Design Diagrams

mermaid
flowchart TB
  subgraph Org[AWS Organization]
    Root[Root]
    SecOU[Security OU]
    SharedOU[Shared OU]
    SandOU[Sandbox OU]
    WorkOU[Workloads OU]
    Root --> SecOU
    Root --> SharedOU
    Root --> SandOU
    Root --> WorkOU
    SecOU --> SecAcct[Security Tooling]
    SharedOU --> NetAcct[Shared Network]
    SharedOU --> IdAcct[Identity]
    WorkOU --> Dev[Dev]
    WorkOU --> Prod[Prod]
  end
  Humans[Humans via Identity Center] --> Dev
  Humans --> Prod
  CI[CI OIDC roles] --> Dev

mermaid
flowchart LR
  TF[Terraform stacks] --> S3[State bucket]
  TF --> Lock[Lock table]
  TF --> Plan[Plan artifact]
  Plan --> Policy[Policy checks]
  Policy --> Apply[Apply with approval]

mermaid
sequenceDiagram
  participant Eng as Engineer
  participant Id as Identity Center
  participant Role as Account Role
  participant API as AWS APIs
  Eng->>Id: Authenticate MFA
  Id->>Role: Assume into workload account
  Role->>API: Scoped actions

Technical Explanation

State boundaries

Corrupt state in a monolith backend can block the entire company. Split stacks: management-org, security-baseline, network-hub, workload-<env>. Document restore from state versioning.

Account vending

Minimum viable: manual account create + apply account_baseline module. Advanced: Account Factory / AFT / custom Step Functions—only use documented AWS patterns; do not invent APIs. Portfolio can stop at manual+module with a future ADR.

SCP intent examples (conceptual)

Deny organizations:LeaveOrganization; deny disabling CloudTrail/Config in prod OU; deny creation of resources outside allowed regions. Always validate JSON against AWS SCP docs; test in sandbox OU first.

Cross-account roles

OrganizationAccountAccessRole or custom roles with trust to management/CI. Prefer short sessions; require external ID where third parties exist. Humans via Identity Center permission sets mapped to groups.

Policy as code

Example checks: S3 buckets must have encryption; security groups deny 0.0.0.0/0 on SSH; IAM policies deny *:*. Fail CI on HIGH. Exact tool flags: read current Checkov/tfsec docs.

Networking deferred

Hub-and-spoke TGW belongs in Shared Network account (lesson 52). This project ships an ADR placeholder and optional empty module rather than forcing full TGW spend.

Failure tests

Apply a deny-region SCP in sandbox; show create in forbidden region fails.
Attempt assume-role without MFA/trust; show denial.
Capture screenshots/CLI stderr—no invented error codes.

Cleanup ethics

Destroy workload lab accounts’ resources. Closing accounts has waiting periods and process—follow AWS account closure documentation. Do not automate org deletion.

Practical Implementation or Design Walkthrough

Problem

Deliver modular Terraform, remote state, policy validation, and operating guidance for TechLearningPro’s multi-account skeleton.

Steps

Budget in management and each lab account; tag Project=tlp-lesson67.
Draw OU/account diagram; get peer review.
Create state backend (bucket policies, encryption, lock).
Implement account_baseline module (budget, mandatory tags via defaults, CloudTrail/Config as permitted).
Apply to one sandbox account; plan for a second.
Add CI policy checks on example insecure Terraform; show fail then fix.
Write runbook: vend account, map Identity Center access, apply baseline.
Failure tests as above; ADR-6701/6702; evidence pack.
Cleanup lab resources; document what must remain if org structure is retained.

Enterprise Real-World Scenarios

Clickops account sprawl

Teams create accounts with no baseline; GuardDuty missing. Fix: no account without baseline module apply evidence.

SCP breaks CI

Over-broad deny blocks CodeBuild. Fix: sandbox exceptions carefully scoped; test plans.

Shared state file

Two teams apply over each other. Fix: split state; locking; CODEOWNERS.

Control Tower + DIY conflict

Two account factories fight. Fix: single ADR owner for vending path.

Break-glass abuse

Standing admin in prod. Fix: time-bounded elevation, tickets, CloudTrail review.

Best Practices

Management account for org only.
Split Terraform state by blast radius.
Baseline every account.
Policy-as-code in CI.
Test SCPs in sandbox OU.
Identity Center for humans; OIDC for CI.
Tag + budget mandatory.
Document break-glass.
Version modules.
Approve applies to prod/management.
Prefer preventive SCPs + detective Config.
Avoid dual Control Tower/DIY factories.
Plan network hub separately.
Never commit secrets or state.
Cleanup without destroying the org.

Common Mistakes and Anti-Patterns

Using management account for workloads.
One global terraform state.
SCPs first tested in prod.
AdminAccess for all developers.
Inventing Control Tower API payloads.
No budget on new accounts.
Closing accounts as casual destroy without process.
Ignoring Organizations external ID/trust hygiene.
Policy tools not enforced—warnings only forever.
Copy-pasting SCP JSON from random blogs without docs check.

Troubleshooting and Design Review

Symptom	Cause	Action
AccessDenied on apply	SCP or missing role	Decode auth error; check SCP
State lock stuck	Crashed apply	Verify lock; break only with process
Drift	Clickops	Replan; restrict console
CI cannot assume	Trust policy	Fix OIDC subject claims
Config cost spike	All resources recorded	Scope recorders thoughtfully
Account limit	Quotas	Request increase via documented process

Interview Questions and Answers

Q1: Why multi-account? A: Blast radius, billing, security boundaries, environment isolation.
Q2: SCP vs IAM? A: SCP preventive max permissions for accounts; IAM grants within.
Q3: State strategy? A: Remote, locked, split by stack.
Q4: Control Tower vs Terraform? A: Speed/baselines vs flexibility—ADR required.
Q5: Break-glass? A: MFA, logged, time-bound, reviewed.
Q6: Policy as code? A: Block risky plans pre-apply.
Q7: Identity? A: Identity Center permission sets; no long-lived keys.
Q8: Where do apps go? A: Workload OUs—Projects 64–66.
Q9: Failure test? A: Denied region create; failed assume-role.
Q10: Cost? A: Logging/security services + shared network.
Q11: Account vending? A: Baseline module mandatory; automation optional.
Q12: Management account use? A: Org/billing only.
Q13: Drift? A: Scheduled plan + restrict clickops.
Q14: Network? A: Shared hub later via TGW ADR.
Q15: Portfolio proof? A: Diagram, modules, plan+policy evidence, runbook, ADRs.

Hands-On Exercises

Exercise: Modular IaC, remote state, policy validation, operating guidance

Deliverable: Module repo, plans, policy CI evidence, two failure tests, ADRs, cleanup notes that protect the org.

Challenge ADR

Under stricter compliance, require SCP deny of non-home regions in prod OU within 14 days; accept sandbox exemption with expiry ADR.

Lab evidence checklist

OU diagram, Terraform modules, remote state design, policy-check fail/pass evidence, assume-role deny evidence, ADRs, runbook; budget/cleanup confirmation.

Narrative: An engineer nearly disabled CloudTrail in a shared account; SCP deny plus baseline module evidence stopped the outage of accountability

An engineer nearly disabled CloudTrail in a shared account; SCP deny plus baseline module evidence stopped the outage of accountability.

Continuity

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Deep dive: ADR template (TechLearningPro)

text
# ADR-NNNN: Title
Date:
Status: Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
Context:
Decision:
Consequences:
Evidence / links:

Deep dive: Portfolio README skeleton

text
TechLearningPro Project — Lesson 67
- Problem / NFRs
- Architecture (diagram + service rationale)
- Repo layout
- Deploy / destroy
- Security checklist
- Observability
- Failure tests
- Cost notes (illustrative; verify pricing)
- ADRs

Deep dive: Budget and tagging

Create or verify a budget with email/SNS subscriber before any apply. Tag Project=tlp-lesson67, Owner=<you>, Environment=lab. Screenshot Cost Explorer filtered by tag after destroy to prove idle cost returned near zero (allow for delayed billing).

Extended enterprise scenario: acquisition pressure

Leadership wants the lab promoted as “production-ready marketing copy.” Refuse without PRR evidence from lesson 63, WAR risks from lesson 58, and failure-test artifacts from this lesson.

Extended enterprise scenario: disputed decision

Two senior engineers disagree on the primary architecture choice. Run a timeboxed RFC, record ADR with revisit date, and keep the rejected alternative documented so interviews and audits see the trade-off—not silence.

Extended practice scenario 1 — 67 terraform multi-account landing zone

Confirm AWS Budgets alerts exist for the sandbox; tag every resource Project=tlp-lesson67. Do not proceed without a budget subscriber.

In a timed drill for Terraform multi-account landing zone at TechLearningPro, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: OU diagram, Terraform modules, remote state design, policy-check fail/pass evidence, assume-role deny evidence, ADRs, runbook, and destroy confirmation for any lab resources.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating Terraform multi-account landing zone as a mystery.

Extended practice scenario 2 — 67 terraform multi-account landing zone

Document the lesson's primary architecture decision in a ten-line ADR: context, decision, status, consequences.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 3 — 67 terraform multi-account landing zone

Map identity paths: who can create/modify the resources in this lesson; which IAM roles are least privilege.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 4 — 67 terraform multi-account landing zone

Design observability: CloudWatch metrics/alarms or equivalent signals that prove the control works.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 5 — 67 terraform multi-account landing zone

Run or design a negative test: denied access, misconfiguration, or failed dependency—capture evidence.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 6 — 67 terraform multi-account landing zone

Estimate cost dimensions for this lesson's activities. Label figures illustrative; verify pricing pages with dates.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 7 — 67 terraform multi-account landing zone

Produce a cleanup checklist and execute destroy for any billable lab resources created for lesson 67.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 8 — 67 terraform multi-account landing zone

Cross-link prior course lessons that this design depends on; list two failure modes inherited from those layers.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 9 — 67 terraform multi-account landing zone

Security review: encryption at rest/in transit, public exposure checks, CloudTrail visibility for management events.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 10 — 67 terraform multi-account landing zone

Reliability review: failure injection, rollback path, how detection and recovery work.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 11 — 67 terraform multi-account landing zone

Performance review: throughput, latency, or scaling limits relevant to Terraform multi-account landing zone at TechLearningPro.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 12 — 67 terraform multi-account landing zone

Write a runbook section for on-call: symptoms, first three diagnostic steps, escalation, rollback.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 13 — 67 terraform multi-account landing zone

Config/compliance angle: which controls must be true before production promotion.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 14 — 67 terraform multi-account landing zone

Multi-account consideration: how this workload sits in landing-zone OU boundaries from lessons 48–49 and 67.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 15 — 67 terraform multi-account landing zone

Interview drill: explain Terraform multi-account landing zone at TechLearningPro to a hiring manager in three minutes without inventing APIs.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 16 — 67 terraform multi-account landing zone

Pair review: partner stops any invented CLI flags, hardcoded secrets, or fake current prices.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 17 — 67 terraform multi-account landing zone

FinOps continuity from lesson 47: idle resources, data transfer, and when to decommission lab stacks.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 18 — 67 terraform multi-account landing zone

DR continuity from lesson 45 and 68: recoverability must survive the change you are shipping.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 19 — 67 terraform multi-account landing zone

Produce evidence pack: diagrams, configs, test results, cleanup proof.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 20 — 67 terraform multi-account landing zone

Challenge constraint: tighter monthly budget—what do you sequence differently?

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 21 — 67 terraform multi-account landing zone

Challenge constraint: stricter compliance—what evidence gates promotion?

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 22 — 67 terraform multi-account landing zone

Challenge constraint: shorter maintenance window—what pre-staging changes?

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 23 — 67 terraform multi-account landing zone

Teach-back: recite the Lesson Overview paragraph, then check against the text; flashcard gaps.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 24 — 67 terraform multi-account landing zone

Dress rehearsal: tabletop under a timer with observer notes.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Extended practice scenario 25 — 67 terraform multi-account landing zone

Final synthesis note: one paragraph connecting Terraform multi-account landing zone at TechLearningPro to TechLearningPro production ownership.

Hosts accounts for Projects 64–66 and feeds security baselines into Project 5 (68). Next lesson wires SRE/DR across those platforms.

Compliance evidence pack for auditors / platform leads

Budget configs, tagging proof (Project=tlp-lesson67), architecture diagram, ADR, negative-test evidence, encryption settings notes, CloudTrail/Config references where applicable, pricing-page retrieval dates for any dollar claims, cleanup confirmation.

Glossary drill

Review every bold term introduced in Detailed Core Concepts and Interview Q&A. Write one sentence definitions from memory; correct against the lesson. Unfamiliar AWS console navigation becomes a lab note, not a guess. Focus terms: OU, SCP, remote state, permission set, account baseline, break-glass.

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers. I deleted or scheduled deletion for orphan lab resources from lesson 67 named ____. I labeled every savings or cost figure with pricing-page retrieval dates or marked it illustrative. Signed ________ date ________.

Interview story to memorize

Craft a 60-second story: TechLearningPro needed Terraform multi-account landing zone; you chose a design with explicit trade-offs; you proved it with tests; you governed cost with budgets and tags; you left an ADR so the next engineer does not reverse the decision blindly. Mention blast radius and state splitting.

Self-assessment rubric

Area	Weight
Conceptual accuracy and service selection	20%
Working design/lab and reproducibility	25%
Security and least-privilege	20%
Reliability, observability, troubleshooting	20%
Documentation, ADR, cleanup	15%

Final synthesis before summary

Mastery of Terraform multi-account landing zone at TechLearningPro is not logo recognition—it is owning failure modes, cost meters, identity boundaries, and the written decision that keeps TechLearningPro coherent under change.

Extended facilitation script (print for guild leads)

Open with single-account horror story. Ask who can disable logging, where state lives, and how a new account gets budgets on day one. Demand SCP test evidence. Close by mapping Enrollment API and Orders to workload accounts.

Lesson Summary

A Terraform multi-account landing zone gives TechLearningPro isolation, baselines, remote state discipline, and policy-checked changes—without treating the management account as a playground. Tag Project=tlp-lesson67; destroy lab resources carefully without reckless org deletion.

Next: Project 5: Observability, SRE and Disaster Recovery.