AWS Organizations Account Creation and Role Switching | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson covers how to create an AWS Organization, add a new AWS account from the management account, enable Service Control Policies, and access the new account using IAM role switching. This is important for the SAP-C02 exam because multi-account strategy, centralized governance, account isolation, and organizational controls are common themes in scenario-based questions.

Key Concepts

AWS Organizations Overview

AWS Organizations is the AWS service used to centrally manage multiple AWS accounts. Instead of running all workloads inside one AWS account, organizations can separate workloads, environments, teams, or business units into different accounts.

At the Solutions Architect Professional level, AWS expects you to understand that multi-account design is a best practice for security, governance, billing, and operational separation.

Common account separation examples include:

Management account
Production account
Development account
Security account
Logging account
Shared services account
Sandbox account

Using separate accounts helps reduce blast radius. For example, a mistake in a development account should not directly affect production workloads.

Management Account

When an AWS Organization is created, the account used to create the organization becomes the management account.

The management account is the root administrative account for the organization. It can:

Create new AWS accounts
Invite existing AWS accounts
Manage organizational units
Enable policy types
Attach Service Control Policies
View consolidated billing information
Manage organization-wide governance settings

For exam purposes, remember that the management account should be protected carefully. It should not be used for normal workloads.

A real-world best practice is to keep the management account as clean as possible and use it only for organization-level administration, billing, and governance.

Organization Root

After creating an organization, AWS creates a top-level root container.

The organization root is not the same thing as the AWS account root user. The organization root is the top of the AWS Organizations hierarchy.

Accounts and organizational units can exist under the organization root.

Example hierarchy:

Organization Root
└── Management Account
└── Production OU
    └── Production Account
└── Development OU
    └── Development Account

The root is where policies can be applied broadly across the entire organization. However, in production environments, it is usually better to apply policies to specific organizational units instead of applying everything directly at the root.

Creating an AWS Organization

Creating an AWS Organization is straightforward from the AWS Management Console.

The high-level process is:

AWS Management Console
→ AWS Organizations
→ Create organization

Once created, the current AWS account becomes the management account.

The organization provides centralized billing, centralized account management, and policy-based governance.

Creating vs. Inviting AWS Accounts

AWS Organizations supports two main ways to add accounts:

Method	Description
Create account	AWS Organizations creates a brand-new AWS account under the organization
Invite account	An existing AWS account is invited to join the organization

Create Account

Creating an account is useful when you are building a new environment from scratch.

For example:

Management Account
→ Create new account
→ DCT-production

AWS asks for:

Account name
Unique email address
IAM role name for cross-account access

The default role name commonly used is:

OrganizationAccountAccessRole

This role allows administrators in the management account to switch into the newly created member account.

Invite Existing Account

Inviting an account is useful when an organization already has standalone AWS accounts that need to be brought under centralized governance.

This is common during migrations, acquisitions, or cloud governance cleanup projects.

For example, a company may have several AWS accounts created by different teams over time. AWS Organizations allows those accounts to be invited into a centralized structure.

Email Address Requirement for New AWS Accounts

Every AWS account requires a unique email address.

When creating multiple AWS accounts, you need a unique email for each one. Some organizations use distribution lists, shared mailboxes, or email aliases.

Examples:

aws-prod@example.com
aws-dev@example.com
aws-security@example.com
aws-logging@example.com

Some email platforms support alias formats, such as plus-addressing:

cloudadmin+prod@example.com
cloudadmin+dev@example.com
cloudadmin+security@example.com

This can simplify account creation while still allowing each AWS account to have a unique email identity.

Email Verification

After AWS Organizations creates a new account, AWS sends a verification email to the address associated with that account.

The email address should be verified so the account can be fully managed and recovered if needed.

In real environments, this is important because account recovery depends heavily on access to the account email address.

Root User in Newly Created Accounts

Every AWS account has a root user associated with the account email address.

When AWS Organizations creates a new account, the root user exists, but you do not directly set a password during account creation.

To log in as the root user, you would need to go through the password reset process for that account email address.

However, best practice is not to use the root user for routine administration.

Instead, administrative access should be performed through IAM roles, IAM Identity Center, or another federated access model.

OrganizationAccountAccessRole

When a new account is created through AWS Organizations, AWS can create a cross-account IAM role in the new member account.

The commonly used default role name is:

OrganizationAccountAccessRole

This role allows users from the management account to switch into the member account.

This is an important concept for the exam because role switching is a common way to administer multiple AWS accounts without creating separate IAM users in every account.

Switching Roles Between AWS Accounts

After creating the member account, an administrator can switch roles from the management account into the new account.

Required information includes:

Required Value	Description
Account ID	The AWS account ID of the target member account
Role name	The IAM role to assume, such as OrganizationAccountAccessRole
Display name	Friendly label shown in the AWS Console
Color	Optional console color indicator to help visually distinguish accounts

Once the role is assumed, the administrator operates inside the target account.

For example, if the administrator switches into the production account and opens EC2, they are viewing EC2 resources in the production account, not the management account.

This visual distinction matters in real operations because engineers can accidentally make changes in the wrong AWS account if they are not careful.

Service Control Policies

Service Control Policies, or SCPs, are organization-level guardrail policies.

They control the maximum available permissions for AWS accounts within an organization.

An SCP does not grant permissions by itself. It only defines what permissions are allowed or denied at the organization level.

A user or role still needs IAM permissions inside the AWS account. The effective permission is the intersection of:

IAM permissions
+
Service Control Policies
+
Permission boundaries, if used
+
Resource policies, if applicable

Enabling Service Control Policies

SCPs must be enabled before they can be used.

After enabling SCPs, AWS provides a default policy called:

FullAWSAccess

This policy allows access to all AWS services and actions.

By default, accounts need FullAWSAccess or another policy that allows required actions. If an SCP does not allow an action, that action is not available even if IAM allows it.

SCPs and the Management Account

A critical exam point is that SCPs do not restrict users or roles in the management account.

SCPs apply to member accounts in the organization, but they do not limit what principals can do in the management account.

This is a common exam trap.

If a question asks how to restrict the management account itself, SCPs are not the answer. You would need to use IAM policies, permission boundaries, least privilege access, MFA, root user protection, or other identity controls.

SCPs as Guardrails

SCPs are commonly used to prevent dangerous or non-compliant actions across accounts.

Examples include:

Deny disabling CloudTrail
Deny leaving the organization
Deny use of unapproved AWS Regions
Deny deletion of security logging resources
Deny creation of public S3 buckets
Deny use of expensive services in sandbox accounts

SCPs are especially useful in large environments where centralized governance is required.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember that AWS Organizations is the primary service for centrally managing multiple AWS accounts.

The management account is the account that creates and manages the organization. It should not host production workloads.

New accounts can be created directly from AWS Organizations or existing accounts can be invited.

Each AWS account requires a unique email address.

When AWS Organizations creates a new member account, cross-account access can be enabled using an IAM role such as OrganizationAccountAccessRole.

Administrators can use the AWS Console switch role feature to assume a role in another AWS account.

Service Control Policies define the maximum permissions available to member accounts.

SCPs do not grant access. IAM permissions are still required.

SCPs do not restrict the management account.

The default FullAWSAccess SCP allows all actions and is commonly attached by default so accounts are not accidentally locked down.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Need centralized management for multiple AWS accounts	AWS Organizations	Provides account management, consolidated billing, and policy-based governance
Need to create a brand-new production account	AWS Organizations create account	Creates a new member account directly under the organization
Need to bring existing AWS accounts under central governance	AWS Organizations invite account	Allows standalone accounts to join the organization
Need to administer a member account from the management account	IAM role switching	Allows cross-account access without creating separate IAM users
Need to apply guardrails across accounts	Service Control Policies	SCPs define the maximum available permissions for accounts
Need to restrict what can happen inside the management account	IAM policies and security controls	SCPs do not restrict the management account
Need environment separation between production and development	Separate AWS accounts	Reduces blast radius and improves governance
Need to organize accounts by workload or business function	Organizational Units	OUs allow policy application to groups of accounts

Common Exam Traps

Trap 1: Thinking SCPs Grant Permissions

SCPs do not grant permissions.

They only define the maximum permissions that can be used. A principal still needs IAM permissions inside the account.

Bad assumption:

Attach an SCP that allows EC2, and the user can now manage EC2.

Correct understanding:

The SCP allows EC2 at the organization level, but the user still needs IAM permissions for EC2.

Trap 2: Thinking SCPs Restrict the Management Account

SCPs do not restrict the management account.

If the exam asks about restricting actions in the management account, look for IAM-based controls, MFA, least privilege, or root user protections instead.

Trap 3: Using One Account for Everything

For professional-level architecture, using one AWS account for all workloads is usually not the best answer.

AWS expects architects to use multi-account design for isolation, governance, and security.

Trap 4: Confusing Organization Root with Account Root User

The organization root is the top-level container in AWS Organizations.

The AWS account root user is the all-powerful identity associated with an individual AWS account email address.

They are different concepts.

Trap 5: Forgetting Each AWS Account Needs a Unique Email

Every AWS account needs a unique email address.

This matters when designing large-scale account vending or landing zone strategies.

Trap 6: Assuming You Need IAM Users in Every Account

You do not need to create separate IAM users in every account for administration.

Cross-account IAM roles, IAM Identity Center, and federation are preferred patterns.

Real-World Engineer Notes

In a real AWS environment, AWS Organizations is usually one of the first services configured when building a proper cloud foundation.

The management account should be treated like a highly privileged control plane. Engineers should avoid deploying workloads there. Instead, workloads should live in member accounts.

For production environments, you would usually go beyond manually creating accounts in the console. Larger environments often use AWS Control Tower, account vending automation, IAM Identity Center, and standardized organizational units.

A basic structure might look like this:

Management Account
Security OU
  └── Log Archive Account
  └── Security Tooling Account
Infrastructure OU
  └── Shared Services Account
Workloads OU
  └── Production Account
  └── Development Account
Sandbox OU
  └── Sandbox Account

Role switching is useful for learning and small environments, but in larger enterprises, federated access through IAM Identity Center is generally easier to govern and audit.

Console colors and role display names may seem minor, but they help prevent operational mistakes. Accidentally deploying or deleting resources in the wrong account is a real risk.

SCPs should be tested carefully. A poorly designed SCP can block required services or break automation pipelines. In production, SCP changes should go through change control, testing, and staged rollout.

A good governance approach is to start with broad access, then gradually introduce deny-based guardrails for high-risk actions.

Examples of useful SCP guardrails include:

Deny disabling CloudTrail
Deny deleting centralized logging buckets
Deny use of non-approved Regions
Deny changing AWS Config settings
Deny removing security tooling
Deny leaving the organization

For account email addresses, use a controlled mailbox strategy. Do not use personal employee email addresses for AWS root account ownership. If the employee leaves, account recovery becomes harder.

Quick Reference Summary

AWS Organizations is used to centrally manage multiple AWS accounts.

The account that creates the organization becomes the management account.

The organization root is the top-level container for accounts and OUs.

Accounts can be created directly or invited into the organization.

Each AWS account requires a unique email address.

AWS Organizations can create a cross-account IAM role such as OrganizationAccountAccessRole.

Administrators can switch roles into member accounts using the account ID and role name.

Service Control Policies define maximum allowed permissions for member accounts.

SCPs do not grant permissions.

SCPs do not restrict the management account.

The default FullAWSAccess SCP allows all actions.

Use separate AWS accounts for workload isolation, governance, billing, and blast-radius reduction.

Flashcards

Q: What AWS service is used to centrally manage multiple AWS accounts?
A: AWS Organizations.

Q: What is the management account in AWS Organizations?
A: The AWS account that creates and manages the organization.

Q: What is the organization root?
A: The top-level container in AWS Organizations where accounts and OUs exist.

Q: Can AWS Organizations create new AWS accounts?
A: Yes. It can create new member accounts directly from the management account.

Q: Can AWS Organizations add existing AWS accounts?
A: Yes. Existing accounts can be invited to join the organization.

Q: What role is commonly created for cross-account access into a new member account?
A: OrganizationAccountAccessRole.

Q: What information is needed to switch roles into another AWS account from the console?
A: The target account ID and the role name.

Q: What does an SCP do?
A: It defines the maximum available permissions for accounts in an organization.

Q: Does an SCP grant permissions?
A: No. IAM permissions are still required.

Q: Do SCPs restrict the AWS Organizations management account?
A: No. SCPs do not restrict principals in the management account.

Q: What is the default SCP commonly attached when SCPs are enabled?
A: FullAWSAccess.

Q: Why should workloads usually not run in the management account?
A: The management account is highly privileged and should be reserved for organization-level administration and billing.

Q: Why use separate AWS accounts for production and development?
A: To improve isolation, reduce blast radius, and apply different governance controls.

Q: Why does every AWS account need a unique email address?
A: The account email is tied to the AWS account root user and account recovery.

Q: What is a common use case for SCPs?
A: Preventing member accounts from performing risky or non-compliant actions, such as disabling CloudTrail or using unapproved Regions.

Practice Questions

Question 1:
A company wants to centrally manage billing, governance, and account creation across multiple AWS accounts. Which AWS service should be used?

A. AWS IAM
B. AWS Organizations
C. AWS Config
D. AWS CloudFormation

Correct Answer:
B. AWS Organizations

Explanation:
AWS Organizations is used to centrally manage multiple AWS accounts, including account creation, consolidated billing, and policy-based governance.

Question 2:
An administrator enables Service Control Policies in AWS Organizations. They attach an SCP that allows access to Amazon EC2. A user in a member account still cannot launch EC2 instances. What is the most likely reason?

A. SCPs do not apply to member accounts
B. SCPs only work with the root user
C. SCPs do not grant permissions by themselves
D. SCPs only apply to billing permissions

Correct Answer:
C. SCPs do not grant permissions by themselves

Explanation:
SCPs define the maximum permissions available, but IAM permissions are still required inside the AWS account.

Question 3:
A company wants to prevent member accounts from disabling security controls, but the same SCP does not restrict the management account. Why?

A. SCPs only apply to IAM users
B. SCPs do not restrict the management account
C. SCPs require AWS Control Tower
D. SCPs only apply after CloudTrail is enabled

Correct Answer:
B. SCPs do not restrict the management account

Explanation:
Service Control Policies apply to member accounts in the organization, but they do not restrict principals in the management account.

Question 4:
A cloud administrator creates a new AWS account using AWS Organizations. They want to access the new account from the management account without creating a separate IAM user in the new account. What should they use?

A. Root user password reset
B. IAM access keys from the management account
C. AWS Console switch role using OrganizationAccountAccessRole
D. S3 bucket policy

Correct Answer:
C. AWS Console switch role using OrganizationAccountAccessRole

Explanation:
AWS Organizations can create a cross-account role in the new member account. Administrators can switch into that role using the target account ID and role name.

Question 5:
A company has several standalone AWS accounts that were created by different teams. The company now wants to bring them under centralized governance. What should the company do?

A. Delete the accounts and recreate them
B. Invite the existing accounts into AWS Organizations
C. Convert the accounts into IAM users
D. Move all resources into the management account

Correct Answer:
B. Invite the existing accounts into AWS Organizations

Explanation:
AWS Organizations supports inviting existing AWS accounts into an organization so they can be centrally governed.