AWS Account Setup, IAM Identity Center and Organizations

AWS Cloud & DevOps Engineering · Lesson 02 · AWS Cloud Foundations

Lesson Overview

The Region decision from Cloud Computing and AWS Global Infrastructure does not tell you who can change production. On the Tuesday after TechLearningPro's first AWS pilot, a shared IAM user password lived in a team chat pin, a "sandbox" bucket held a copy of enrollment exports, and the same account paid for experiments and for the Monday board's early warehouse spike. When someone deleted a stack they thought was temporary, CloudTrail showed a long-lived access key that should never have existed. The outage was small. The lesson was not: an AWS account is a blast-radius boundary, not a folder label.

This lesson builds the landing-zone primitives for the TechLearningPro learning platform: how to think about account setup, AWS Organizations, organizational units (OUs), service control policies (SCPs) at a conceptual level, consolidated billing, and IAM Identity Center (successor to AWS Single Sign-On) for human access with temporary credentials. You will propose development, staging, and production account boundaries for learner progress APIs and the Monday board without pretending that one account with clever tags is multi-environment isolation.

Deep Control Tower automation, advanced SCP catalogs, and multi-account networking appear in AWS Organizations, Control Tower and Landing Zones and Cross-Account Access and Multi-Account Networking. AWS Identity and Access Management deepens policies inside an account. This lesson makes the boundaries those lessons inherit.

Planning assumptions:

• TechLearningPro will run at least separate accounts for production workloads, non-production workloads, and security/logging—exact OU names can vary, but the separation of duties should not.
• Humans authenticate through a corporate identity provider federated to IAM Identity Center when available; long-lived IAM users for people are an exception with an expiry, not a culture.
• Illustrative organization diagrams are teaching shapes. Match them to your company's naming and to current AWS Organizations documentation before implementation.
• Enrollment-week staffing pressure is not an accepted reason to reopen shared credentials or to copy production databases into developer accounts. The account design is the pressure valve: sandbox speed and synthetic data must be good enough that the shortcut stops being attractive.
• Cost figures in classroom discussions remain illustrative until Cost Explorer and the current price card replace them. Account structure should make those figures attributable even when the numbers change.

Learning Objectives

By the end of this lesson you will be able to:

1. Explain why an AWS account is a security, billing, and blast-radius boundary for the learning platform.
2. Describe AWS Organizations management (payer) and member accounts, OUs, and the purpose of SCPs without inventing policy JSON you have not verified.
3. Propose a practical account split for development, staging, and production—including where shared services and log archives belong.
4. Contrast IAM Identity Center permission sets with long-lived IAM users and access keys for human operators.
5. Map human access flows from IdP → Identity Center → permission set → account role assumption.
6. Explain consolidated billing benefits and the cost-allocation habits (accounts, tags) FinOps will later need.
7. Identify root user duties, MFA expectations, and break-glass patterns at a design level.
8. Recognize anti-patterns: shared credentials, production data in sandbox accounts, and SCPs that break Break Glass or logging.
9. Draft an account-boundary ADR TechLearningPro can implement gradually without a big-bang rewrite.
10. Prepare the identity story that lesson 3 (IAM) and lesson 4 (CLI/SDK) will operationalize with least privilege.

Prerequisites

• Lesson 1 vocabulary: Region, AZ, shared responsibility, sandbox versus production data classes.
• Ability to read a simple directory of people and teams (who is platform engineering, who is application engineering, who is finance).
• No requirement to already own an Organizations management account; the exercises can be design-only if your employer restricts org changes.
• Optional: skim /learn/git only to remember that infrastructure changes will later flow through reviewed commits—account design should not depend on chat-ops as the source of truth.

Detailed Core Concepts

Why accounts exist

When TechLearningPro's pilot lived in one account, every conversation about risk collapsed into tagging debates. Someone would argue that env=prod versus env=dev was enough isolation because "our developers know not to touch prod." That social contract fails the first time a script defaults to the wrong profile, the first time a contractor laptop is compromised, and the first time an IAM policy uses a wildcard resource on Friday afternoon. Accounts restore a technical default deny that does not depend on perfect human memory.

Tags organize cost and ownership inside an account. They do not stop a role with broad IAM power from reading every bucket in that account. Separate accounts give you:

1. Hard isolation by default. IAM principals in account A cannot access resources in account B unless you create explicit cross-account trust.
2. Independent quotas. A load test in development should not exhaust production API quotas in the same account.
3. Clearer blast radius. A bad script with Admin-like power devastates one account, not the entire company estate—unless you also granted cross-account admin everywhere.
4. Billing and chargeback surfaces. Consolidated billing still lets you see per-account spend.
5. Policy guardrails at the org boundary. SCPs can deny entire categories of actions across an OU regardless of what an administrator inside the account attempts (with important caveats around the management account and service-linked roles—verify current docs when you write SCPs).

For TechLearningPro, learner PII and production progress data belong in production-class accounts. Synthetic learners and empty schemas belong in development. Staging should use anonymized or synthetic data by policy, not "a copy of prod because QA wanted realism" without a written exception.

Root user, account bootstrap, and break-glass

Every AWS account has a root user identity associated with the account owner email. The root user can perform actions that IAM principals cannot (account-level lifecycle operations). Treat root as break-glass:

• Enable MFA on root immediately.
• Do not create long-lived access keys for root.
• Use root only for a documented list of tasks (for example, account settings that require root—confirm the current list in AWS documentation when you need one).
• Store recovery procedures in a secure vault with dual control where your security team requires it.

Initial account setup also includes contacts, alternate contacts for billing/security/operations, CloudTrail/config baselines (deepened later), and deciding whether the account joins an organization.

AWS Organizations

AWS Organizations lets you centrally govern multiple accounts. Key ideas:

• Management account (formerly called master): the organization creator; owns consolidated billing; has special powers and should not run ordinary application workloads.
• Member accounts: workload and supporting accounts.
• Organizational units (OUs): tree nodes for grouping accounts (for example, Platform, Workloads/Prod, Workloads/NonProd, Sandbox, Security).
• Service control policies (SCPs): organization-level guardrails that limit the maximum permissions available to principals in member accounts. SCPs do not grant permissions; they set a ceiling. IAM still must allow the action.
• Consolidated billing: one payer invoice with per-account cost visibility; volume discount aggregation may apply per AWS pricing terms—check current billing docs rather than assuming a discount story.

A minimal teaching OU sketch for TechLearningPro:

Names vary. The invariant is: production data plane accounts are not playgrounds, and the management account is not an app account.

IAM Identity Center

IAM Identity Center is the AWS-recommended approach for workforce access across accounts. Conceptually:

1. Users and groups come from an external identity provider (OIDC/SAML) or from Identity Center's directory.
2. You define permission sets—templates of IAM policies that Identity Center provisions as IAM roles into selected accounts.
3. Users receive access assignments: who × which permission set × which account.
4. Sign-in yields temporary credentials via federation, not permanent access keys in laptops by default.

This replaces the anti-pattern of creating IAM users per human in every account. Application workloads still use IAM roles (instance profiles, task roles, Lambda execution roles)—humans and machines are different identity classes. Lesson 3 elaborates.

Identity Center also gives you a single place to revoke a departing engineer's access across accounts by removing the user or group assignment, rather than hunting access keys.

Permission sets versus IAM policies inside an account

A permission set might be named TLP-Developer, TLP-ReadOnly, TLP-PlatformAdmin, TLP-BillingView. Each maps to policies that should be least privilege. Resist AdministratorAccess for daily work. Platform admins may need elevated sets with MFA and shorter session durations; developers building the lesson API in the dev account need power to create resources there, not to modify production SCPs.

SCPs might deny LeaveOrganization, deny disabling CloudTrail in production OUs, deny creating resources in non-approved Regions, or deny copying snapshots to accounts outside the org—examples of intent. Exact JSON must be authored against current AWS docs and tested in non-prod OUs first. An SCP that accidentally denies the logging account permission to deliver logs is a self-inflicted blindfold.

Consolidated billing and cost allocation

Organizations consolidates invoices to the management account. Engineering still needs:

• Account-level spend as the first slice (prod vs staging vs sandbox).
• Tags for service ownership inside an account (service=progress-api, env=prod).
• Budgets per account or aggregated with filters.
• No shared production account for random POCs.

Finance will ask why sandbox spent as much as staging. The answer should be visible without archaeology. Later FinOps lessons expand Cost Explorer practices; here, design accounts so the questions are answerable.

Human access flow end-to-end

1. Engineer signs in through corporate IdP.
2. IdP asserts identity to IAM Identity Center.
3. Engineer selects an account and permission set (role).
4. Identity Center provides short-lived credentials to console or AWS CLI / SSO session.
5. API calls carry that role's identity into CloudTrail.

Break-glass: a tightly controlled path for production incident response when IdP is unavailable—documented, monitored, rarely used, MFA-enforced. Do not make break-glass the daily driver.

Cross-account access preview

Applications and pipelines often need to assume roles across accounts (for example, CI in a shared tools account deploying into staging/prod). The pattern is an IAM role in the target account with a trust policy allowing a specific principal in the source account, plus least-privilege permissions. Details and networking implications wait for lessons 3, 4, and 49. Mentally register: cross-account is explicit trust, never ambient.

Staging, production, and the Monday board

Suggested boundaries for TechLearningPro:

• tlp-dev: engineers iterate on progress API; synthetic data only; permissive but budget-bounded.
• tlp-staging: production-like topology; synthetic or scrubbed data; same Region story as prod when testing failover behavior.
• tlp-prod-app: player-facing APIs and web tiers.
• tlp-prod-data (optional split): analytics/Monday board warehouse and data lake—so a warehouse admin role is not automatically an OLTP admin.
• tlp-security / log archive: organization trail destination, config snapshots—write-once access patterns.
• Management account: Organizations only; no learner workloads.

Whether you split app and data now or later is a staffing trade-off. Document the decision. A single prod account is acceptable for early stage only if SCPs, Identity Center, and ruthless IAM hygiene exist—and if you have a dated plan to split when blast radius outgrows comfort.

Account vending and lifecycle

Accounts are not immortal folders. They are created, governed, sometimes quarantined, and occasionally closed. A lightweight lifecycle for TechLearningPro:

1. Request. A team asks for an account with purpose, data class, OU, budget owner, and expiry if sandbox.
2. Provision. Create account via Organizations APIs or your vending pipeline (Control Tower Account Factory appears in later lessons). Apply baseline: CloudTrail membership, Config (when adopted), Identity Center assignments, budget, mandatory tags on the account itself where supported.
3. Operate. Workloads deploy through CI roles, not human standing admin.
4. Review. Quarterly access reviews for permission set assignments; cost reviews for sandbox sprawl.
5. Quarantine. If compromise is suspected, move to a Suspended OU with aggressive SCPs, rotate credentials, preserve logs.
6. Close. Follow AWS account closure process only after backups, DNS, and payment implications are understood. Never casually close the management account.

Without lifecycle, "temporary" accounts become unpaid museums of Elastic IPs and old RDS snapshots.

Baseline security in every member account

Account setup is incomplete until a baseline exists. Foundations-level baseline (expand later with Config and Security Hub):

• CloudTrail enabled and delivering to the log archive account (organization trail preferred when available).
• Default VPC assessment: many enterprises delete or tightly control default VPCs to prevent accidental public resources; if you keep them, document why.
• Account-level S3 Block Public Access defaults where your standard requires it.
• No IAM users for humans as the default path.
• MFA on root; secure storage of root recovery procedures.
• Budgets or anomaly detection appropriate to the account class.
• Contact details for billing, security, and operations so AWS notices reach humans who can act.

The baseline should be code or a checklist with owners. A wiki page that nobody runs is not a baseline.

Separating CI/CD identity from human identity

Pipelines that deploy the lesson API should assume a deploy role in the target account. Humans who approve changes use Identity Center roles for investigation and break-glass. If humans and pipelines share the same broad role, every laptop becomes a deploy credential. Lesson 4 and Module 3 deepen CI patterns; the account design must leave room for a tools or shared-services account that owns runners without owning production data.

The Monday board and data account boundaries

The Monday completion board tempts teams to grant analysts broad production access "so they can debug numbers." Prefer:

• Curated exports or a warehouse in a data account.
• Read-only permission sets scoped to those datasets.
• No direct psql to production OLTP from analyst laptops.
• Clear ownership when board numbers disagree with the player (a data contract problem, not an excuse to merge accounts).

This mirrors the data-engineering boundary already taught on TechLearningPro: operational systems of record versus derived analytical products. Cloud accounts should reinforce that boundary, not erase it.

Sandbox rules that survive contact with deadlines

Write sandbox rules that security will still defend during launch week:

• No production PII, no production snapshots, no production secrets.
• Budget cap with automated alert; optional hard actions your FinOps process allows.
• Aggressive TTL tags; weekly sweeper for expired resources where automation exists.
• Internet egress allowed for learning, but not for becoming an open relay or uncontrolled crypto miner—monitor with GuardDuty later.
• Identity Center assignments time-bounded for contractors.

If sandbox is more painful than using prod for experiments, engineers will use prod for experiments. Make sandbox fast to get and hard to misuse.

Naming conventions

Pick a naming scheme and keep it boring:

• Accounts: tlp-<env>-<function> such as tlp-prod-app.
• OUs: stable nouns, not team names that reorganize quarterly.
• Permission sets: TLP-<Persona>-<AccessLevel>.
• Cost tags: project, service, owner, env, ttl.

Renaming accounts later is awkward; renaming mental models mid-incident is worse. Publish the convention in the same ADR as the OU tree.

Gradual migration from a pilot account

Most teams reading this already have a pilot. A big-bang freeze-and-move fails. Prefer:

1. Stand up Organizations and Identity Center while the pilot still runs.
2. Create empty target accounts with baselines.
3. Stop creating new production resources in the pilot.
4. Move services one at a time with DNS cutovers and data migration plans.
5. Convert human access to Identity Center; delete access keys with a published date.
6. Reclassify the pilot as sandbox or decommission it after the last workload leaves.

Communicate the date when production credentials in the pilot become invalid. Ambiguous dual-running is how keys live forever.

Architecture and Design Diagrams

mermaidCopy
flowchart TB
  subgraph idp [Corporate IdP]
    Users[Engineers and operators]
  end

  subgraph sso [IAM Identity Center]
    PS[Permission sets]
  end

  subgraph org [AWS Organizations]
    Mgmt[Management account]
    OUProd[OU Workloads Prod]
    OUNon[OU Workloads NonProd]
    OUSec[OU Security]
    ProdApp[tlp-prod-app]
    Staging[tlp-staging]
    Dev[tlp-dev]
    LogArch[Log archive]
  end

  Users --> sso
  PS --> ProdApp
  PS --> Staging
  PS --> Dev
  Mgmt --> OUProd
  Mgmt --> OUNon
  Mgmt --> OUSec
  OUProd --> ProdApp
  OUNon --> Staging
  OUNon --> Dev
  OUSec --> LogArch

mermaidCopy
sequenceDiagram
  participant Eng as Engineer
  participant IdP as Corporate IdP
  participant IC as IAM Identity Center
  participant Acct as Member account role
  participant CT as CloudTrail

  Eng->>IdP: Authenticate MFA
  IdP->>IC: Federation assertion
  Eng->>IC: Choose account + permission set
  IC->>Acct: Temporary credentials / role session
  Eng->>Acct: AWS API calls
  Acct->>CT: Record identity and action

Technical Explanation

Account as authorization boundary

IAM policies reference resources that live in accounts. Cross-account access requires resource policies and/or role trust relationships. That indirection is the point: you cannot "accidentally" list production buckets from a developer role that only exists in tlp-dev unless someone built a trust path. Review every trust path like a product feature.

SCPs as ceilings

If an SCP denies s3:* to an OU (extreme example), even an AdministratorAccess permission set cannot perform S3 actions there. That power is how organizations enforce "no IAM users," "no disable logging," or "only approved Regions." It is also how organizations brick accounts if they deny required actions for Break Glass or for AWS services that need to function. Always test SCPs on a sandbox OU. Remember SCPs do not apply in the same way to the management account—do not place workloads there to "escape" SCPs.

Identity Center permission set provisioning

When you assign a permission set to an account, Identity Center creates or updates a corresponding IAM role in that account and manages its lifecycle. Engineers do not need to hand-craft parallel roles in twelve accounts for human access. Workload roles remain separate and should not be interchangeable with human permission sets.

Session duration, MFA requirements at the IdP, and device posture (where your company uses it) are part of the security design. Shorter sessions for production admin sets reduce the window of stolen temporary credentials.

Billing linkage

Member accounts' charges roll to the management account payer. Closing accounts, removing accounts from the organization, and credits have specific processes—follow current Organizations and Billing documentation when you do them. For course work, never experiment with account closure on a production payer.

Root versus federated admin

Root is account-global and rarely used. Federated admin through Identity Center is auditable per person. If your CloudTrail events show maggie@example.com assumed TLP-PlatformAdmin, you can run an incident. If they show a shared IAM user admin, you can only run an argument.

How Organizations interacts with IAM evaluation

When a principal in a member account calls an API, AWS evaluates identity-based policies, resource-based policies when applicable, permission boundaries, session policies, and organization SCPs. A deny in an applicable SCP means the action is denied even if an IAM policy allows it. That is why SCPs are described as a ceiling. They are not a replacement for least-privilege IAM; a permissive IAM policy under a loose SCP is still dangerous.

Important nuances to verify in current documentation when you implement:

• SCPs affect IAM users and roles in member accounts; the management account is not constrained the same way—another reason not to run apps there.
• Service-linked roles and AWS service principals may require careful SCP design so you do not break AWS services you rely on.
• SCPs do not grant; an empty IAM policy with a permissive SCP still denies by default for identity-based evaluation.

Design reviews should ask: "If this account's IAM administrator becomes hostile or compromised, which actions can SCPs still stop?" Logging protection, Region restriction, and forbidding organization departure are classic answers. "Stop every bad SQL query" is not an SCP job.

Permission set design for TechLearningPro personas

Translate personas into permission sets with explicit intent:

Exact managed policies versus customer-managed policies belong in lesson 3. Here, refuse to collapse everything into one TLP-AllAccess set. Launch-week convenience becomes permanent privilege.

Federation failure modes

Identity Center depends on your IdP being available and correctly configured. Failure modes:

• IdP outage blocks normal human access—break-glass must exist and be tested.
• Wrong group mappings grant prod access to the wrong team—access reviews catch drift.
• Clock skew and certificate expiry break SAML/OIDC—monitor IdP certificate lifecycles.
• Engineers copy temporary credentials into .env files and commit them—lesson 4 and secret scanning address this; culture must forbid it.

Write the federation runbook beside the account ADR. An identity outage during a production incident is a compound failure.

Multi-account networking foreshadow

Once accounts multiply, networks must interconnect deliberately: shared services VPC, Transit Gateway, PrivateLink, or isolated accounts with no east-west paths. Do not peer every VPC to every other VPC "for convenience." Account isolation dies when network paths recreate a flat estate. Lessons 6, 7, 49, 50, and 52 build that carefully. For now, when you draw accounts, draw a dotted note: "network attachment TBD—default deny across accounts."

Cost allocation IDs and chargeback stories

Consolidated billing answers "what did AWS charge us?" Chargeback answers "which product owed which slice?" Accounts give you a coarse chargeback dimension for free. Tags give fine dimensions inside an account. If Finance only receives a single undifferentiated invoice narrative, they will invent their own spreadsheet—and that spreadsheet will disagree with Cost Explorer. Align early on:

• Who owns sandbox spend?
• Is staging charged to platform or to product squads?
• Are data-transfer costs attributed to the producer or consumer account?

Illustrative only: if sandbox historically burns a noticeable fraction of non-prod spend, a budget alert at a fixed USD threshold (set by your policy, verified in Budgets) pays for itself the first time a forgotten load test runs over a weekend. Replace any classroom dollar figure with your live numbers before making staffing decisions.

Practical Implementation or Design Walkthrough

Budget alert first

In each sandbox or member account you can control, configure AWS Budgets with an alert email before creating resources. Training orgs often start with a low monthly threshold; pick a number your policy allows and verify Budgets options in current docs. Tag resources with owner and ttl.

Design walkthrough: propose env account boundaries

Work through this worksheet and keep it as an ADR.

1. List environments: sandbox, dev, staging, prod, security/logging, management.
2. List data classes per environment: forbidden, synthetic, scrubbed, production.
3. List human personas: developer, platform admin, SRE read-only, finance billing viewer, data engineer (Monday board), break-glass.
4. Map personas to permission sets and accounts. Developers do not get prod write by default. Data engineers get prod-data read paths that are still least privilege.
5. Decide OU placement and which SCP intents apply (Region lock, deny root keys, deny leaving org, protect CloudTrail). Do not paste unverified JSON into production.
6. Define federation: IdP groups → Identity Center groups → assignments.
7. Define break-glass procedure at prose level: who, MFA, logging, post-incident revocation.
8. Define migration steps from a single-account pilot: create org (if needed), invite/create accounts, move workloads gradually, cut over SSO, delete long-lived human access keys.

Console orientation (when you have access)

• Organizations console: tree of OUs and accounts (read-only browsing first).
• IAM Identity Center: identity source, permission sets, account assignments.
• Billing: confirm consolidated view and account-level costs.
• IAM: verify you are not accumulating IAM users for humans as the primary pattern.

CLI orientation (read-only examples)

bashCopy
aws organizations describe-organization
aws organizations list-accounts
aws sso-admin list-instances

Exact subcommands and required permissions vary; if a call is denied, that is itself useful evidence of least privilege. Do not attach AdministratorAccess to "make the demo work" in production.

Negative paths to document

1. Developer permission set attempted in prod → expect deny (no assignment or SCP/IAM deny).
2. Access key create for a human IAM user in prod OU → should be prevented by process and preferably by guardrail intent.
3. Copy of production snapshot shared to personal/sandbox account → deny by policy and process.

Step-by-step design session (ninety minutes)

Use this agenda when facilitating the account-boundary exercise with TechLearningPro stakeholders.

Minutes 0–10: Facts on the table. List current accounts, who has keys, where production data lives, and last month's spend by account if available. No redesign yet. The discomfort of seeing shared keys is intentional.

Minutes 10–25: Data classes and environments. Agree what "production data" means for enrollments, progress, and Monday board extracts. Agree that staging will not receive unscrubbed production snapshots without a written exception and expiry.

Minutes 25–45: Target OU and account diagram. Draw the tree. Argue about whether prod-data splits now or later. Capture the decision and the revisit date. Explicitly mark the management account as non-workload.

Minutes 45–60: Personas and permission sets. Build the matrix. Remove any row that says "everyone needs admin in prod for speed." Replace with operator and break-glass paths.

Minutes 60–75: Guardrail intents and federation. List SCP intents and IdP groups. Assign owners to draft (not merge) SCPs in a sandbox OU next week.

Minutes 75–90: Migration milestones. Pick dates for: Identity Center mandatory for humans; pilot account stop-creating-prod; first workload move; key deletion day. Put budget alerts on every account before the week ends.

Exit criteria: an ADR merged to the platform repo via normal /learn/git review practice, not a slide deck lost in email.

Evidence pack for auditors and leadership

When leadership asks "are we multi-account yet?" show evidence, not slogans:

• Organizations tree screenshot or CLI list-accounts output (redact account IDs in external decks if required).
• Identity Center assignment export for prod permission sets.
• CloudTrail organization trail destination account ID.
• Budget configurations for sandbox accounts.
• Written break-glass procedure with last test date.
• List of remaining human IAM access keys with owners and deletion dates.

Auditors respond to artifacts. Engineers respond to deletion dates. Provide both.

What "good" looks like after ninety days

• Humans sign in through Identity Center; standing access keys for people are zero or documented exceptions.
• Production learner traffic runs in a member account that is not the management account.
• Sandbox spend is visible and alerting.
• A leaver loses AWS access when IdP disables the user—verified with a test account.
• At least one SCP intent is enforced in non-prod and scheduled for prod after soak time.
• Cross-account deploy roles exist on paper with least-privilege scopes, even if CI is still maturing.

If ninety days later the pilot account is still everything, the ADR failed—not the cloud.

Enterprise Real-World Scenarios

Scenario A: Shared IAM user in chat

A startup culture created tlp-shared IAM user keys in Slack. An ex-contractor still had the key. Staging was cryptomined overnight.

Fix. Identity Center with per-person assignments; disable keys; CloudTrail investigation; rotate everything the key could touch; budget alerts; SCP/process against human access keys.

Scenario B: Prod data in "dev"

QA restored a production RDS snapshot into the shared developer account for "realistic testing." A broad developer role could read enrollment emails.

Fix. Data classification rules; scrubbed or synthetic datasets; separate accounts; deny snapshot share outside prod/staging with controlled pipelines.

Scenario C: Management account runs the app

Teams deployed the lesson API into the Organizations management account because "billing already worked there." SCPs did not constrain it; blast radius included org governance.

Fix. Move workloads to member accounts; reserve management for org governance only.

Scenario D: SCP bricks deployments

An SCP denied all IAM role creation to enforce "no wild roles," which also blocked Identity Center permission set provisioning and some AWS services.

Fix. Test SCPs in sandbox OU; allowlist service-linked paths carefully; treat SCPs as code with review.

Scenario E: Staging equals prod access

Permission set Developer was assigned to both staging and prod for convenience during a launch week and never removed.

Fix. Time-bounded assignments; access reviews; separate prod elevate set with MFA and shorter sessions.

Best Practices

1. Prefer IAM Identity Center for humans; reserve IAM users for break-glass or exceptional automation that cannot yet federate—with expiry.
2. Keep the management account free of application workloads.
3. Separate production data from sandbox by account, not only by tags.
4. Use OUs to apply consistent guardrail intents.
5. Assign least-privilege permission sets; review AdministratorAccess like production root.
6. Put organization CloudTrail/log archive strategy in a dedicated account early.
7. Attach budgets to sandbox and non-prod aggressively.
8. Document break-glass and test that CloudTrail shows who used it.
9. Plan cross-account deploy roles explicitly; do not share long-lived keys across accounts.
10. Treat account structure as architecture: ADR, review, incremental migration.
11. Give every account a human budget owner who receives alerts—not a mailing list that everyone filters away.
12. Time-box elevated prod assignments; calendar the removal when launch week ends.
13. Keep synthetic data tooling funded so engineers are not tempted to clone prod.
14. Align account design with the Region/AZ ADR from lesson 1 so every new account inherits placement rules.
15. Review permission set assignments when teams reorganize; group mappings drift silently.

Common Mistakes and Anti-Patterns

1. One account for everything. Symptom: quota fights, blurry audit, huge blast radius. Fix: split by env and data class.
2. Long-lived access keys for people. Symptom: leaked keys, impossible attribution. Fix: Identity Center temporary creds.
3. Workloads in the management account. Symptom: governance risk. Fix: migrate to member accounts.
4. SCPs written once, never tested. Symptom: mysterious denies or false safety. Fix: sandbox OU experiments and change management.
5. Prod data in non-prod accounts. Symptom: privacy incidents. Fix: classification + technical controls.
6. Permission sets that mirror AdministratorAccess for all engineers. Symptom: silent privilege. Fix: tiered sets and just-in-time elevation patterns your org supports.
7. No alternate contacts / no budget alerts. Symptom: unpaid bills or unnoticed spend. Fix: account contact hygiene and Budgets.
8. Assuming tags equal isolation. Symptom: "env=dev" resource readable by prod role in same account. Fix: account boundaries.
9. Flat VPC peering across every account. Symptom: account isolation without network isolation. Fix: deliberate hub patterns in later networking lessons; default deny.
10. Orphan sandboxes without TTL. Symptom: permanent low-grade spend and shadow IT. Fix: account lifecycle and sweeper policies.
11. Break-glass used as daily admin. Symptom: unreviewed standing power. Fix: monitor break-glass role assumption; require tickets.
12. Deleting CloudTrail to "save money" in prod. Symptom: irreversible blindness. Fix: SCP intents protecting trails; log archive account with restricted write.

Troubleshooting and Design Review

User can sign into Identity Center but sees no accounts. Check assignments for group membership, correct Identity Center instance, and whether permission sets provisioned into the account.

Access denied despite AdministratorAccess permission set. Look for SCPs, permission boundaries, session policies, or wrong account. SCPs are ceilings.

Consolidated bill is opaque. Enable account-level Cost Explorer views and enforce tagging; confirm you are not mixing sandbox noise into mental "prod burn."

Root MFA lost. Follow AWS account recovery procedures with governance; treat as a severity incident. Do not create root access keys as a workaround.

Design review questions

• Which accounts hold production learner PII?
• Who can assume prod admin, for how long, with what MFA?
• What SCP intents protect logging and Region use?
• How does a leaver lose all AWS access in one business day?
• Where do CI roles live, and what do they trust?
• Are budgets alerting on sandbox?
• Is the management account workload-free?

Interview Questions and Answers

Q1. Why not use one AWS account with tags for environments?

Tags aid cost and operations but do not provide hard IAM isolation. A principal with broad rights can cross tag boundaries. Accounts create default deny across boundaries without explicit trust.

Q2. What problem does IAM Identity Center solve?

Central workforce authentication and authorization across accounts using permission sets and temporary credentials, replacing per-account IAM users for humans and improving revocation and audit.

Q3. Do SCPs grant permissions?

No. They define maximum available permissions (a ceiling). Identity-based and resource-based policies must still allow the action.

Q4. Why keep workloads out of the management account?

The management account has unique organizational powers and billing centrality. Running apps there expands blast radius into governance itself and weakens SCP strategy.

Q5. How would you structure accounts for TechLearningPro?

Separate management, security/logging, non-production, and production accounts at minimum; consider splitting production app and analytics; sandboxes isolated with budget caps and data bans.

Q6. What is a permission set?

A reusable IAM policy template Identity Center provisions into accounts as roles and assigns to users or groups for those accounts.

Q7. How does consolidated billing interact with FinOps?

One invoice, many account cost centers. You still allocate by account and tags; consolidation does not remove the need for ownership.

Q8. What is break-glass access?

A tightly controlled emergency path when normal federation fails or for rare root tasks—logged, MFA-protected, reviewed afterward.

Q9. How do you prevent production data from landing in dev?

Account separation, SCP/policy guardrails on snapshot sharing, pipeline controls, and contractual synthetic data requirements for non-prod.

Q10. What goes wrong if developers share an IAM user?

No personal attribution, painful rotation, leakage amplification, and failed incident response. Use per-person federation.

Q11. How do Organizations and IAM interact in an access decision?

All relevant policy types are evaluated; an SCP deny wins against an IAM allow for constrained accounts. Interview answers should mention that evaluation is layered and that docs should be checked for the exact evaluation order diagram.

Q12. When is a single production account acceptable?

Early stage with strong Identity Center hygiene, logging, budgets, and a dated split plan—never as an unexamined default after PII and uptime stakes rise.

Hands-On Exercises

Lab cost warning. Prefer design-only if you cannot create accounts. Creating accounts may have organizational implications; follow your company's process. Set budget alerts in any account where you create resources. Clean up experimental IAM users, access keys, and billable resources.

Exercise: Propose development, staging, and production account boundaries

Problem. TechLearningPro currently has one pilot account. Draft the multi-account target state and migration sequence.

Tasks.

1. Confirm or create a budget alert in the pilot/sandbox account.
2. Produce an OU and account diagram (Mermaid or draw.io) covering management, security, dev, staging, prod (and optional prod-data).
3. Write persona → permission set → account assignment tables.
4. Write data-class rules per account.
5. List five SCP intents (not unverified JSON) with test plans on a sandbox OU.
6. Document IdP group mapping and leaver revocation steps.
7. List all long-lived human credentials to eliminate, with owners.
8. Cleanup: delete any lab IAM users/keys you created; verify Identity Center assignments for your test user are intentional; remove unused billable resources.

Deliverables. ADR, diagram, assignment table, SCP intent list, cleanup evidence.

Challenge. Add a constraint: contractors may develop features but must never read production enrollment PII—even if production APIs are down and "just this once" is requested. Show how account boundaries and permission sets enforce the refusal.

Exercise 2: Access-key elimination backlog

Problem. Inventory human IAM users and access keys in the pilot account (read-only listing). Build a backlog that removes them without stranding automation.

Tasks.

1. Set or verify a budget alert before any other change.
2. List IAM users and note which have access keys (console or CLI). Do not print secret key material—ever.
3. Classify each user: human, unused, automation candidate for role migration, break-glass exception.
4. For each human user, map the replacement Identity Center permission sets and accounts.
5. For automation users, sketch the target role trust (CI principal or workload identity)—implementation may wait for lessons 3–4 and Module 3.
6. Publish a deletion date and communications plan.
7. Cleanup: remove only keys you own in a sandbox lab user you created for this exercise; never delete production keys without change control. Document what you would delete under change control.

Deliverables. Inventory table, replacement map, dated cutover plan, cleanup notes for lab-only principals.

Exercise 3: Break-glass tabletop

Problem. Run a thirty-minute tabletop: IdP is unavailable during a production incident affecting the lesson player.

Tasks.

1. Write who can invoke break-glass, where credentials or roles live, and how MFA works offline relative to the IdP.
2. Write how CloudTrail (or equivalent) will show the session.
3. Write the post-incident revocation and review steps.
4. Identify two ways the procedure could fail (lost MFA device, undocumented password) and mitigations.
5. No billable resources required; if you create any test role in sandbox, delete it afterward.

Deliverables. One-page runbook section and failure mitigations.

Lesson Summary

AWS accounts are blast-radius, quota, and data-class boundaries. Organizations arranges those accounts under OUs with consolidated billing and optional SCP ceilings. IAM Identity Center gives humans federated, temporary, per-person access through permission sets instead of shared long-lived keys. TechLearningPro's landing zone starts when development, staging, production, and security/logging stop sharing one pilot account's fate. Baselines, lifecycles, and migration dates turn the diagram into an operating system for the platform rather than a slide.

Next, AWS Identity and Access Management goes inside the account to roles, policies, trust relationships, and evaluation logic. AWS CLI, SDKs and Infrastructure Access then shows how engineers and pipelines obtain and use temporary credentials safely. Keep your account ADR; every IAM role you write later should know which account it belongs to and why. When Module 5 returns to Control Tower and multi-account networking, you should recognize the same OU tree—only with more automation and stricter guardrails.

Further Reading

• AWS Organizations User Guide for accounts, OUs, and SCPs.
• IAM Identity Center User Guide for permission sets and identity sources.
• AWS account root user for root responsibilities and MFA.
• Consolidated billing for payer and member billing behavior.
• AWS Budgets for sandbox spend alerts.
• Later course lessons on Control Tower and cross-account patterns for implementation depth beyond this foundations cut.