Large AWS environments need more than IAM policies inside individual accounts. AWS Organizations provides the account hierarchy and organization-wide policy boundary, IAM Identity Center provides centralized workforce access, and service control policies (SCPs) define maximum permissions for member accounts and organizational units. These services work together, but none of them replaces the others.

When analyzing independent SAA-C03 architecture practice, the key is to separate identity, permission grants, and organization guardrails. If a scenario says that users need centrally managed access to many accounts, that is an identity and assignment problem. If it says no member account should be able to disable a required security service, that is a guardrail problem. If it says accounts must be grouped for governance and billing, that begins with Organizations.

Use Organizations to create the multi-account structure

AWS Organizations lets a company manage multiple AWS accounts as one organization. Accounts can be grouped into organizational units (OUs), and OUs can be nested to represent governance boundaries such as production, development, security, infrastructure, or business units. Consolidated billing and organization-wide management features then operate across that structure.

A multi-account model improves isolation because workloads do not all share one enormous IAM and resource boundary. Production can be separated from development. Security tooling can live in dedicated accounts. Teams can receive budgets and permissions appropriate to their responsibilities. A compromised workload account does not automatically become the same failure domain as the organization’s management account.

The management account is special. It owns the organization and performs organization-level administration. Because many organization controls do not restrict principals in the management account the same way they restrict member accounts, administrators should minimize routine workload activity and human access there.

Design OUs as policy boundaries, not just folders

An OU is valuable because organization policies can be attached at a level that reflects the intended control scope. A security SCP can apply to every account under a production OU, while a less restrictive policy can apply to a sandbox OU. Accounts inherit applicable SCPs from the root and parent OUs, so hierarchy directly affects effective permissions.

That means an OU design should be stable enough to represent governance. Creating an OU for every project merely to make the console look tidy can make policy behavior difficult to reason about. A better structure groups accounts that need the same organization-level controls, then uses tags, account metadata, and workload tooling for other classification needs.

Moving an account between OUs is also a policy change because its inherited controls can change immediately. Account-move procedures should therefore be reviewed like other security changes instead of treated as harmless administration.

Use IAM Identity Center for workforce access across accounts

IAM Identity Center provides a central way to assign workforce users and groups access to AWS accounts and applications. It can integrate with an external identity provider or use the Identity Center directory, depending on the organization’s identity architecture. Users receive a portal and can select from the accounts and roles that have been assigned to them.

This is different from creating long-lived IAM users in every member account. Centralized federation makes joiner, mover, and leaver processes easier because workforce identity can be managed from one system. It also reduces the temptation to create separate passwords and access keys across dozens of accounts.

In a mature environment, the identity source proves who the person is, Identity Center maps that identity to account assignments, and AWS IAM roles inside the target accounts represent the permissions that are actually assumed.

Permission sets define what assigned users receive

IAM Identity Center permission sets are templates for the access that users or groups receive in target AWS accounts. A permission set can include AWS managed policies, customer managed policy references, inline policy content, session duration, and other settings. When the permission set is assigned to an account, IAM Identity Center provisions the corresponding role into that account.

This makes permission sets a grant mechanism. A ReadOnly permission set might give an operations group visibility across many accounts. A more privileged permission set might be available only to an on-call engineering group. The same permission set can be assigned consistently rather than manually recreating IAM roles in every account.

Delegated administration can move most IAM Identity Center administration to a designated member account, reducing the number of people who need routine access to the Organizations management account. The Identity Center instance remains associated with the organization, but day-to-day administration can be separated from management-account use.

Use SCPs to set the maximum permission boundary

Service control policies are organization guardrails. They define the maximum actions that principals in affected member accounts can perform. An SCP does not grant permission. Instead, an action must be allowed by the applicable organization guardrails and by the normal IAM or resource policies that grant access.

For example, an administrator role in a member account may have an IAM policy that allows ec2:*. If an applicable SCP explicitly denies the creation of internet gateways, the role still cannot create one. The IAM policy is a grant, while the SCP limits the maximum effective permissions.

This is why attaching an Allow statement in an SCP does not by itself let a user call an API. The user still needs an identity-based or resource-based permission path. In allow-list SCP models, the required action also has to remain allowed through the organization policy hierarchy.

Remember that explicit denies and the management account change the outcome

An explicit deny in an applicable policy overrides an allow. SCP troubleshooting should therefore examine the policy hierarchy from the organization root through each parent OU to the account. A broad deny at a parent level cannot be bypassed by adding a more permissive IAM role in the member account.

SCPs apply to principals in member accounts, including highly privileged principals, but they do not restrict users or roles in the management account. That is one reason the management account should be treated as a high-trust administrative boundary with minimal daily use.

AWS Organizations also supports additional organization policy types beyond SCPs, including resource control policies for supported services and other management policies. These are separate mechanisms. An architect should not assume that every organization policy is an SCP or that every policy type affects permissions in the same way.

Keep identity grants and guardrails conceptually separate

A useful model is to think in layers. The workforce identity system establishes the human identity. IAM Identity Center assignments and permission sets create a path to assume roles in member accounts. IAM identity-based and resource-based policies participate in granting access to resources. SCPs and other applicable organization controls restrict the maximum permission set.

If a user cannot perform an action, check every layer that participates. Was the user assigned the right account and permission set? Was the corresponding role provisioned? Does the role policy allow the API? Does a resource policy impose another condition? Does an SCP or resource control policy deny it? Is a permissions boundary or session policy involved?

This layered method is much faster than repeatedly making the role “more admin” and hoping the error disappears. More IAM permission cannot override an organization-level explicit deny.

Build account governance around blast radius and responsibility

Organizations is most effective when the account model follows operational responsibility. Security, log archive, shared networking, identity, production workloads, and experimentation frequently have different trust and change requirements. Separate accounts create boundaries for IAM, quotas, billing, logging, and incident response that a single-account design cannot reproduce as cleanly.

Organization-level guardrails can then prevent known-dangerous actions while leaving application teams freedom inside the permitted boundary. For example, an SCP might prevent member accounts from leaving the organization or from disabling designated security controls. The detailed workload permissions still belong in IAM roles and service policies rather than in a giant SCP that attempts to describe every permitted API call.

Where centralized account provisioning is required, services such as AWS Control Tower can build on Organizations, but the underlying concepts remain the same: account structure, identity assignment, and maximum-permission guardrails are distinct design concerns.

Trace effective access from organization to session

When a scenario combines Organizations, IAM Identity Center, and SCPs, solve it by tracing the request. First identify the account and its OU ancestry. Determine which organization policies apply. Then identify how the user or workload obtained its role and what IAM policies, resource policies, permissions boundaries, or session policies participate. Finally evaluate explicit denies and the intersection of the permission layers.

Use AWS Organizations for the account hierarchy and organization-wide governance. Use IAM Identity Center for centralized workforce access and account assignments. Use permission sets to define the role permissions that Identity Center provisions. Use SCPs to establish maximum permissions for member accounts and OUs, not to grant access.

For SAA-C03, that separation is more useful than memorizing console locations. Organizations answers “where does this account sit and what guardrails apply?” IAM Identity Center answers “how does this workforce identity reach the account?” IAM answers “what is granted inside the account?” The effective permission is the result of all relevant layers together.