Week 1 Synthesis & Multi-Account Drill
Week 1 Recap
Week 1 built a single governance model out of five services that are easy to learn separately and hard to combine correctly. AWS Organizations gave us the account as the unit of isolation, with Organizational Units mirroring the business and a management account deliberately kept workload-free because SCPs cannot constrain it. SCPs then supplied the permission ceiling — the FullAWSAccess default that permits everything until an explicit Deny narrows it, and the region-restriction pattern that has to exempt global services or it breaks account operations. Control Tower automated the landing zone we would otherwise assemble by hand, provisioning the management, log-archive, and audit accounts and enforcing guardrails as SCPs and Config rules, with Account Factory for Terraform extending that to pipeline-driven provisioning.
On top of that foundation, IAM Identity Center replaced per-account IAM users with permission sets mapped to SAML federation, auto-provisioning a role into each assigned account, while permission boundaries capped what a delegated admin could ever create and STS issued the short-lived credentials underneath. AWS RAM closed the week by inverting ownership: a central network account shares subnets, Transit Gateways, and Resolver rules so application teams launch into a VPC they do not own. The point of the synthesis is that these are not five independent choices — each one assumes the others. Guardrails without account separation have nothing to scope to; SSO without a landing zone has no accounts to assign into; shared networking without SCPs has no way to stop a workload account from re-plumbing the shared VPC.
Foundations You'll Need Today
Today's material is a synthesis of five services, and it leans hard on a handful of ideas that are usually taught as prerequisites rather than explained. If you have only worked at the Cloud Practitioner level, these are the four concepts worth getting straight before the rest of the page makes sense.
An AWS account is a security boundary, not just a billing container
It is tempting to think of an AWS account as a folder that holds your resources and rolls up your bill. It is that, but its more important job is to be a hard wall. Resources in one account cannot see or touch resources in another account by default, and the credentials that exist in one account have no standing in another. That wall is what makes multi-account design possible at all: instead of trying to carve a single account into safe zones with policies, you get separate accounts and the isolation is structural rather than policy-based. When this page talks about "blast radius," it means how much damage a compromised credential could do before it hits a wall — and the wall is the account boundary.
IAM policies, roles, and trust policies
IAM is the system that decides who can do what inside an account. A policy is a JSON document that lists actions (like s3:GetObject) and whether they are allowed or denied. A role is an identity that is not tied to a person — it has no password and no permanent access key. Instead, something assumes the role temporarily and receives short-lived credentials that expire. The trust policy attached to a role is the part that answers "who is allowed to assume me?" — it names the principals (a user, another account, a federated identity provider) that can step into the role. This matters today because IAM Identity Center, permission boundaries, and STS all revolve around roles rather than users, and the exam assumes you know the difference between a policy that grants permissions and a trust policy that controls who can pick up the role in the first place.
Authentication versus authorization
These two words get used interchangeably in casual conversation and mean very different things here. Authentication is proving who you are — logging in, presenting a credential, completing an MFA challenge. Authorization is what you are permitted to do once you are in. A system can authenticate you perfectly and still authorize you to do nothing. Today's identity section separates these deliberately, because IAM Identity Center handles authentication and role assignment while IAM policies and SCPs handle authorization and its ceiling. If you blur the two, you will pick the wrong service for a scenario every time.
VPCs, subnets, CIDR blocks, and route tables
A VPC is a private network you define inside AWS — your own isolated slice of the cloud with its own IP address range. That range is written in CIDR notation, which looks like 10.0.0.0/16 and simply means "this block of addresses." A VPC is divided into subnets, each a smaller slice of that range, usually one per availability zone so resources can be spread across physically separate data centers. Traffic between subnets and out to the internet is directed by route tables, which are exactly what they sound like: a list of destinations and where to send packets headed for each one. A network ACL is a stateless firewall at the subnet boundary, and a security group is a stateful firewall attached to individual resources. Today's networking section assumes all of this, because RAM subnet sharing only makes sense once you understand that a subnet is a piece of a VPC that someone has to own and route.
With that grounding, here is why the five services in this week's synthesis are not five independent choices but one layered model — and why getting the order wrong produces designs that look plausible but fail on a specific constraint.
Identity: Who Gets In, and Who Decides
The first decision boundary in any multi-account design is not which services to use but who holds authority over identity. There are three distinct layers here and scenario questions routinely collapse them into one. The first layer is the human authentication layer: where does a person's credential actually live, and what proves they are who they claim to be. The second is the authorization layer: once authenticated, which role do they assume in which account, and what does that role permit. The third is the ceiling layer: what is the maximum any identity in that account could ever do, regardless of what its policies say. IAM Identity Center, IAM policies, and SCPs each own exactly one of these layers, and a design that puts the wrong service in the wrong layer is the single most common Week 1 mistake.
IAM Identity Center owns authentication and role assignment. It federates from an external IdP — Entra ID, Okta — or uses its own built-in directory, and it maps groups to permission sets. A permission set is not a policy you attach to a user; it is a template that Identity Center materializes as an IAM role inside every account you assign it to. That distinction matters because it means there are no long-lived per-account IAM users to rotate, audit, or accidentally leave behind when someone changes teams. When a scenario says "engineers should log in once and land in the right role across forty accounts," Identity Center is the answer, and any option that proposes creating IAM users per engineer per account is a distractor built on the assumption that identity is per-account rather than per-organization.
SCPs own the ceiling, and they are frequently misread as a grant. They are not. An SCP sets the maximum available permissions for the accounts it is attached to, and an identity still needs an allow from IAM or a resource policy to do anything at all. The practical consequence is that the default FullAWSAccess SCP permits everything until you attach an explicit Deny, which is why a region-restriction SCP has to be written as a Deny with a NotAction exemption list rather than as an Allow of two regions. Permission boundaries occupy a third, narrower position: they cap a single IAM entity rather than a whole account, which is what makes them the right tool for delegated administration.
| Requirement | Service | Why not the others |
|---|---|---|
| Central login across many accounts, no per-account users | IAM Identity Center | SCPs cannot authenticate anyone; permission boundaries cap an entity, they do not federate |
| Prevent any account in an OU from using unapproved regions | SCP on the OU | Identity Center assigns roles, it does not restrict API surface; a boundary is per-entity, not per-OU |
| Let a platform team create roles without letting them create admins | Permission boundary required on CreateRole | An SCP would block the platform team's own account too; Identity Center has no notion of "roles they create" |
| Keep the org's billing and policy root out of blast radius | Organizations management account, kept empty | SCPs do not apply to the management account, so no policy can protect it — only emptiness can |
Guardrails: Hand-Built SCPs vs. Control Tower
Once identity is settled, the next fork is how the guardrails themselves get created and maintained. You can write SCPs by hand, attach them to OUs, and manage the whole thing in Terraform or CloudFormation. Or you can let Control Tower provision the landing zone and express your intent as guardrails, which it implements underneath as SCPs and AWS Config rules. These are not mutually exclusive — Control Tower's guardrails are SCPs — but they represent very different operating models, and the exam tests whether you can tell which one a scenario is actually asking for.
The hand-built path gives you total control and no dependency on a service that owns parts of your organization. It also means you own the account vending process, the log-archive and audit account setup, the baseline Config rules, and the drift detection that tells you when someone has detached a policy. Control Tower gives you all of that as a managed baseline, plus Account Factory for teams that want account creation to be a pipeline operation rather than a ticket. The tradeoff is that Control Tower takes ownership of certain resources in enrolled accounts and imposes its own update cadence, which is a real constraint for organizations with unusual networking or logging requirements.
The guardrail taxonomy is where most scenario questions actually live. Mandatory guardrails cannot be disabled and are always enforced — the classic example being disallow root user access keys. Elective and strongly recommended guardrails are optional best practices you enable per OU based on your governance posture. A question that asks whether a specific control "can be turned off" is testing exactly this distinction, and the answer hinges on whether the control is described as mandatory or elective, not on how important it sounds.
| Signal in the scenario | Pick | Reasoning |
|---|---|---|
| "We need a landing zone in days, not months" | Control Tower | It provisions management, log-archive, and audit accounts plus baseline guardrails automatically |
| "Account creation must be self-service via our Terraform pipeline" | Control Tower + AFT | Account Factory for Terraform layers pipeline-driven provisioning on the Control Tower baseline |
| "We have unusual logging requirements Control Tower cannot express" | Hand-built SCPs and Config rules | Control Tower owns certain resources in enrolled accounts and constrains customization |
| "A control must never be disableable by an OU admin" | Mandatory guardrail | Mandatory guardrails are always enforced; elective ones can be toggled per OU |
Network Ownership: Central VPC vs. Per-Account VPC
The third fork is who owns the network. The traditional model gives every account its own VPC, which means every account owns its own CIDR allocation, its own subnet design, and its own peering or Transit Gateway attachments. The centralized model puts the VPC in a network account and shares subnets outward with AWS RAM, so application accounts launch resources into infrastructure they do not own and cannot reconfigure. Both are legitimate, and the choice is driven by how much network consistency you need versus how much autonomy the application teams need.
RAM subnet sharing is the mechanism that makes the centralized model work, and it is worth being precise about what it does and does not share. The participant account can create resources in the shared subnet — EC2 instances, RDS instances, load balancer nodes — and those resources get IP addresses from the owner's CIDR. The participant cannot modify the subnet, the route tables, the NACLs, or the VPC itself. That asymmetry is the entire value proposition: the network account retains control of routing and security at the network layer while application teams retain control of their own resources. It also means IP address management becomes a single-owner problem instead of a negotiation across dozens of accounts.
The same sharing model extends beyond subnets. Transit Gateways can be shared so that spoke accounts attach to a centrally owned TGW without owning it, and Route 53 Resolver rules can be shared so that every account resolves on-prem names through the same forwarding configuration. When a scenario describes a company that wants "a common, centrally managed network without each account owning its own VPC," RAM is the answer, and VPC peering between every pair of accounts is the distractor that ignores the operational cost of an N-squared mesh.
| Requirement | Approach | Tradeoff |
|---|---|---|
| Uniform routing and IP management across many accounts | Central VPC in a network account, subnets shared via RAM | Application teams cannot change network-layer configuration |
| Application teams need full control of their own network | Per-account VPCs, connected via Transit Gateway | CIDR planning and route management become distributed problems |
| Centralized egress inspection for all accounts | Inspection VPC owned centrally, spokes route 0.0.0.0/0 to a shared TGW | Requires TGW route table segmentation to avoid unintended spoke-to-spoke paths |
| Consistent hybrid DNS resolution everywhere | Resolver rules shared via RAM from the network account | Every account inherits the same forwarding behavior, including its failure modes |
Composing the Five Services Into One Model
The reason Week 1 is a synthesis day rather than five separate topic days is that the exam rarely asks about one of these services in isolation. It asks about a situation — a company with forty accounts, a compliance requirement, a deadline — and expects you to assemble the right combination. The assembly has a natural order, and getting the order wrong produces designs that look plausible but fail on a specific constraint.
Start with the account structure, because everything else scopes to it. Organizations and OUs define the blast-radius boundaries, and the management account stays empty because no SCP can protect it. Then layer the guardrails: SCPs for the permission ceiling, Control Tower if you want the landing zone and account vending automated, Config rules for the detective controls that SCPs cannot express. Then identity: IAM Identity Center for human access, permission boundaries for delegated administration, STS for the machine credentials underneath. Then networking: a central network account owning the VPC and TGW, sharing subnets and Resolver rules via RAM so application accounts consume rather than construct. Each layer assumes the one before it, and a scenario that skips a layer usually has a distractor that fills the gap with the wrong service.
The failure signature to watch for is a design that solves the stated problem but violates an unstated constraint. A single flat account with IAM users per team solves access; it fails isolation. SCPs alone with no account separation solve policy; they fail blast radius, because an SCP cannot protect the account it is attached to from a compromised credential inside it. Control Tower without Identity Center solves provisioning; it leaves human access as per-account IAM users. Reading the scenario for the constraint that is not stated is the skill this week is building.
| Layer | Service | What breaks if you skip it |
|---|---|---|
| Account structure | AWS Organizations + OUs | No scope for guardrails; blast radius is the whole org |
| Permission ceiling | SCPs on OUs | Any identity with a broad policy can act org-wide |
| Landing zone automation | Control Tower (+ AFT) | Account vending and baseline Config become manual and drift-prone |
| Human identity | IAM Identity Center | Per-account IAM users proliferate; offboarding becomes unreliable |
| Delegated admin safety | Permission boundaries | A delegated admin can escalate to AdministratorAccess |
| Network ownership | Central VPC + RAM | CIDR sprawl, N-squared peering, inconsistent egress inspection |
Hands-On Lab: Assemble and Break a Week 1 Landing Zone (60 min)
The goal of this lab is to build the smallest possible version of the Week 1 model and then deliberately break each layer to see what the failure looks like. You will need an AWS Organization with at least four member accounts, or a sandbox where you can create them. Do not run this in an organization that carries production workloads.
Begin by creating the OU structure. Under the root, create a Security OU, an Infrastructure OU, and a Workloads OU with Dev and Prod children. Move your log-archive and audit accounts into Security, and confirm that the management account holds no workloads. This is the structure every later step scopes to, and if you get it wrong here you will be re-doing the SCP attachments later.
Next, attach a region-restriction SCP to the Workloads OU. Write it as a Deny on all actions with a StringNotEquals condition on aws:RequestedRegion for your two approved regions, and a NotAction list exempting IAM, Route 53, CloudFront, and Support. Attach it, then immediately try to create an S3 bucket in an unapproved region from a Dev account and confirm the denial. Then try to create an IAM role from the same account and confirm it still succeeds — that is the global-services exemption working, and it is the single most common way a hand-written region SCP breaks an account.
Now configure IAM Identity Center. Create two permission sets, one granting ReadOnlyAccess and one granting PowerUserAccess, and assign them to a test group with ReadOnlyAccess in Prod and PowerUserAccess in Dev. Sign in as a user in that group and verify that the roles appear in the account chooser and that the Prod role genuinely cannot write. The thing to notice is that no IAM user was created in either account — Identity Center provisioned a role, and when you remove the assignment the role disappears.
Finally, test the ceiling and the boundary. From a Dev account, attach AdministratorAccess to a test role and confirm that the region-restriction SCP still blocks actions outside your approved regions — the intersection of IAM and SCP is what applies, and the explicit Deny wins. Then create a permission boundary that denies iam:* and organizations:*, and create a role with that boundary attached plus AdministratorAccess. Confirm the role cannot modify IAM despite its policy. That is the delegated-admin pattern in miniature.
To close the lab, break things on purpose. Detach the region SCP and observe that the previously denied call now succeeds. Remove the permission boundary from the test role and confirm it can now escalate. Delete the Identity Center assignment and confirm the role vanishes from the account. Each of these is a failure mode you should be able to predict from the design, and being able to predict them is what the exam is measuring.
Mixed Scenario Drill (25 questions)
Q1. A company wants a dedicated account that only aggregates CloudTrail logs from every other account and cannot be modified by workload teams. Where should this account live?
Q2. Why should the AWS Organizations management account never run workloads?
Q3. A developer has an IAM policy granting s3:*, but an SCP on their OU denies s3:DeleteBucket. What happens if they call DeleteBucket?
Q4. A region-restriction SCP is attached to an OU and engineers immediately report that they can no longer create IAM roles or update Route 53 records. What is the most likely cause?
Q5. What is the key difference between a mandatory and an elective Control Tower guardrail?
Q6. A company wants to provision new AWS accounts through its existing Terraform pipelines rather than a manual request process, while keeping Control Tower's baseline guardrails. What should they use?
Q7. An enterprise wants engineers to log in once via their corporate Okta and assume the correct role in any of 40 AWS accounts without individual IAM users. What is the best-practice solution?
Q8. What does IAM Identity Center actually create inside each assigned account when you assign a permission set?
Q9. A delegated admin role can create IAM roles for developers. How do you prevent them from creating a role with AdministratorAccess?
Q10. Which STS operation would an EKS pod use to obtain AWS credentials through its service account, without any long-lived secret?
Q11. A company wants every application account to use a common, centrally managed VPC without each account owning its own VPC. What is the mechanism?
Q12. An application account has been given a shared subnet via AWS RAM. Which of the following can that account do?
Q13. Beyond subnets, which two resources are most commonly shared with AWS RAM in a multi-account landing zone?
Q14. A security team wants to guarantee that no account in the Workloads OU can disable CloudTrail, even if an account administrator has full IAM permissions. What enforces this?
Q15. Which combination best represents a mature multi-account governance baseline?
Q16. A company has 60 accounts and wants a single place to see which accounts exist, which OU each belongs to, and consolidated billing. Which service provides this?
Q17. A team wants to enforce that all new S3 buckets in the Workloads OU are encrypted, and to be alerted when one is not. Which pairing fits?
Q18. An organization wants a central network account to own the VPC and Transit Gateway, with application accounts attaching to the TGW without owning it. What enables the attachment?
Q19. Which statement about SCPs is correct?
Q20. A company is required by regulation to keep all audit logs in an account that workload administrators cannot access, and to prove the logs are retained. Which combination satisfies this?
Q21. A developer needs temporary credentials to call AWS APIs from a CI/CD pipeline running outside AWS. Which approach avoids long-lived access keys?
Q22. Which of these is a legitimate reason to choose a per-account VPC over RAM-shared subnets from a central VPC?
Q23. A company wants to prevent any account in the organization from leaving the organization or changing its own SCP attachments. What should they configure?
Q24. Which service should you use to give a partner company access to a single API hosted in your VPC, when your CIDR ranges overlap?
Q25. A company has built a landing zone with Control Tower, SCPs, Identity Center, and RAM-shared networking. A new workload account is created and immediately launches resources in an unapproved region. Which layer failed?
Preview: Day 8
Everything in Week 1 assumed that accounts need to talk to each other, and the answer we kept reaching for was Transit Gateway — shared via RAM, attached by spokes, segmented by route tables. What we have not done is look at how that segmentation actually works. The open question is what happens when three VPCs all attach to one Transit Gateway and you need Dev and Prod to both reach a shared-services VPC but never reach each other. A single flat TGW route table with everything propagated gives you full mesh connectivity, which is exactly the outcome you were trying to avoid, and no amount of security group configuration fixes a routing decision that was already made at the network layer.
Day 8 takes the Transit Gateway apart: how an attachment associates with one route table and propagates routes into others, why that association-versus-propagation distinction is the whole mechanism, and how to build a hub-and-spoke topology that replaces an unmanageable full mesh of VPC peering. The governance model from this week is the constraint set; the TGW route table is where those constraints become actual packet paths.
Sources
- AWS Organizations — Service control policies (SCPs)
- AWS Control Tower — What is AWS Control Tower?
- IAM Identity Center — What is IAM Identity Center?
- AWS Resource Access Manager — What is AWS RAM?
- IAM — Permissions boundaries for IAM entities
- AWS Whitepaper — Organizing Your AWS Environment Using Multiple Accounts