Create an AWS Organization and Add Member Accounts – SAP-C02 Study Guide

Purpose of This Lesson

AWS Organizations provides centralized governance for multiple AWS accounts. This lesson covers creating an organization, understanding the management account, adding a new member account, organizing accounts into organizational units (OUs), and using the automatically created cross-account administration role.

These capabilities are foundational for multi-account architectures and are frequently tested in AWS Certified Solutions Architect – Professional scenarios involving governance, account isolation, security boundaries, and centralized administration.

Key Concepts

AWS Organizations and the Management Account

When an organization is created, the AWS account used to create it becomes the management account. This account:

• Owns and administers the organization.
• Creates or invites member accounts.
• Creates organizational units and applies organization policies.
• Manages organization-wide settings and integrations.

The management account is a highly privileged account and should not be used for routine workloads. AWS recommends protecting it carefully, enabling MFA, minimizing access, and avoiding the deployment of application resources there.

An organization can use either a consolidated billing or all-features configuration. Features such as service control policies (SCPs) require the appropriate organization feature set to be enabled.

Member Accounts

An account created within AWS Organizations becomes a member account. A member account provides a separate security and billing boundary while remaining subject to organization-level governance.

Member accounts are commonly separated by:

• Environment, such as production, staging, and development.
• Business unit or application domain.
• Security or compliance boundary.
• Infrastructure function, such as logging, security, or networking.

A common structure is a root OU containing OUs such as Security, Infrastructure, Production, and NonProduction.

Creating Versus Inviting an Account

AWS Organizations supports two ways to add an account:

1. Create an AWS account within the organization.
2. Invite an existing AWS account to join the organization.

When creating a new account, the account name and a unique email address are required. The email address cannot already be associated with another AWS account. Account creation may take time to complete, and the console may require a refresh before the final state is displayed.

An invited account remains under the control of its existing owner until the invitation is accepted. This differs from creating an account directly in the organization.

Organizational Units

An organizational unit is a logical container for accounts. OUs allow administrators to apply policies consistently to multiple accounts.

For example:

Root
├── Security
├── Infrastructure
├── Production
│   ├── Production-App
│   └── Production-Data
└── NonProduction
    ├── Development
    └── Test

An account can belong to only one OU at a time, but it can be moved between OUs when the organization administrator has the required permissions.

Service Control Policies

An SCP is a guardrail that defines the maximum permissions available to IAM principals in member accounts. It does not grant permissions by itself.

A principal still requires an identity-based or resource-based policy to perform an action. The effective permission is constrained by the SCP and other applicable policy types.

When SCPs are enabled, AWS Organizations provides a default managed policy named FullAWSAccess. Conceptually, it allows all actions and resources:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This policy does not provide standalone access. It simply ensures that the organization does not impose an additional restriction until more specific SCPs are attached.

Important SCP behavior:

• SCPs apply to member accounts, including their IAM users and roles.
• SCPs do not grant permissions.
• An explicit deny in an SCP overrides an allow elsewhere.
• Permissions must be allowed by every applicable SCP in the hierarchy.
• The management account is not restricted by SCPs.
• SCPs do not affect service-linked roles in the same way as ordinary IAM roles; service-specific behavior must be checked when designing controls.

OrganizationAccountAccessRole

When AWS Organizations creates a member account, it can automatically create an IAM role named:

OrganizationAccountAccessRole

This role normally has the AdministratorAccess managed policy attached. The management account can assume the role to administer the member account.

The role is useful for bootstrapping account configuration, but it should be treated as highly privileged access. In a mature environment, organizations commonly use more controlled administrative roles, delegated administration, AWS IAM Identity Center, or a centralized security access model instead of relying on unrestricted administrator access for daily operations.

To assume the role, the calling principal in the management account needs permission to call sts:AssumeRole, and the target role’s trust policy must trust the calling account or principal.

A console role switch requires:

• The target account ID.
• The target role name.
• A display name for the session.
• Permission for the source identity to assume the role.

Exam-Relevant Takeaways

• The account that creates an AWS Organization is the management account.
• An AWS Organization can contain multiple member accounts, each with its own account ID and security boundary.
• Use OUs to apply governance policies to groups of accounts.
• Creating an account and inviting an existing account are different onboarding workflows.
• A newly created account requires a unique email address.
• OrganizationAccountAccessRole is commonly created automatically when a member account is created through Organizations.
• This role typically provides administrative access, but it is not the same as automatically granting every principal in the management account access.
• SCPs define permission boundaries at the organization level; they do not grant IAM permissions.
• The default FullAWSAccess SCP allows all actions but does not override missing IAM permissions.
• SCPs do not restrict the management account. Do not use the management account as the sole test of an SCP.
• To validate an SCP, test an IAM principal in a member account where the SCP is attached.
• A member account may still receive AccessDenied in the Organizations console because organization administration is performed from the management account; this does not necessarily indicate that the assumed role lacks administrator permissions for other AWS services.

Architecture Decision Guide

Requirement	Recommended AWS Organizations approach	Important consideration
Separate production and development workloads	Create separate member accounts and place them in different OUs	Account boundaries are stronger than tags or naming conventions alone
Apply a restriction to all production accounts	Attach an SCP to the Production OU	The SCP limits maximum permissions; it does not grant access
Onboard a new AWS environment	Create a new member account through Organizations	Use a unique account email address and secure the bootstrap role
Bring an existing account under centralized governance	Send an organization invitation	The account owner must accept the invitation
Centralize initial administration of a new account	Assume OrganizationAccountAccessRole	Restrict who can assume it and monitor its use
Prevent use of unsupported regions	Apply an SCP with an explicit deny for unwanted Regions	Exempt required global services and validate service behavior carefully
Prevent deletion of security logging	Apply deny controls at an appropriate OU level	Test exceptions for security automation and break-glass procedures
Provide routine workforce access across accounts	Use IAM Identity Center and permission sets	Avoid making the management account the daily access portal
Implement multi-account landing zones	Use AWS Control Tower with Organizations	Control Tower adds account factory, controls, and lifecycle automation; Organizations remains the underlying account and policy service

Common Exam Traps

• Assuming an SCP grants access: An SCP is a maximum-permission boundary. IAM policies must still allow the action.
• Assuming FullAWSAccess grants administrator access: It does not. It only removes an organization-level restriction.
• Applying an SCP to the management account: SCPs do not restrict the management account. Place the workload in a member account when testing governance controls.
• Confusing the root user with the organization root: The organization root is a hierarchy container. It is not the AWS account root user.
• Using the management account for workloads: This increases blast radius and complicates governance because SCPs do not constrain it.
• Assuming account creation is instantaneous: Account provisioning can take time, and the console may need refreshing before the account appears ready.
• Reusing an account email address: Each AWS account requires an email address that is not already associated with another account.
• Assuming the role switch grants access to Organizations administration: OrganizationAccountAccessRole administers the member account. Organization-level operations generally belong in the management account or a delegated administrator account.
• Forgetting trust and identity permissions: Cross-account role assumption requires both a trusting role and permission for the source identity to call sts:AssumeRole.
• Treating account names as security controls: Names and tags help identification, but they do not enforce isolation or permissions.

Real-World Engineer Notes

• Use a dedicated management account for AWS Organizations, billing, and governance rather than deploying workloads there.
• Enable MFA and strong authentication controls for the management account, and maintain a protected break-glass process.
• Establish a consistent account naming and email alias strategy before automating account creation.
• Put foundational accounts in dedicated OUs, such as centralized logging, security tooling, networking, and shared services.
• Apply SCPs incrementally. Begin with guardrails that prevent clearly unsafe actions, then test them against deployment pipelines, AWS service integrations, and incident-response procedures.
• Keep an emergency access path. An overly broad SCP can block remediation activities, including actions performed by automation.
• Use AWS CloudTrail organization trails, AWS Config aggregation, and centralized security services to monitor member accounts.
• Prefer IAM Identity Center, permission sets, and short-lived sessions for human access. Avoid distributing long-lived IAM user credentials.
• When using AWS Control Tower, understand which resources and policies it manages. Manual changes to landing-zone resources can cause drift or interfere with lifecycle operations.
• Treat OrganizationAccountAccessRole as bootstrap access. Replace or supplement it with a least-privilege operating model once the account is enrolled and configured.

Quick Reference Summary

• Management account: The account that creates and owns the organization.
• Member account: An account created in or invited into the organization.
• OU: A hierarchy container used to group accounts and apply policies.
• SCP: An organization-level maximum-permission guardrail; it does not grant access.
• FullAWSAccess: Default allow-all SCP used when SCPs are enabled; it does not provide IAM permissions.
• OrganizationAccountAccessRole: Common automatically created administrative role for managing a newly created member account.
• Account creation requirement: A unique email address.
• Cross-account access requirement: sts:AssumeRole permission plus a suitable role trust policy.
• Management account SCP limitation: SCPs do not restrict the management account.
• Control Tower relationship: Control Tower uses AWS Organizations as a foundation for governed multi-account environments.

Flashcards

1. Which AWS account becomes the management account?

The account used to create the AWS Organization.

2. What is the purpose of an organizational unit?

An OU groups AWS accounts so that policies and governance controls can be applied consistently.

3. What is the difference between creating and inviting an account?

Creating provisions a new account in the organization. Inviting requests that an existing account join, subject to acceptance by its owner.

4. What is required when creating a new member account?

An account name and a unique email address that is not already associated with another AWS account.

5. Do SCPs grant permissions?

No. SCPs limit the maximum permissions available to principals in member accounts. IAM or resource policies must still grant access.

6. What does the default FullAWSAccess SCP do?

It allows all actions and resources at the organization-policy layer, preventing a default SCP restriction. It does not grant IAM access.

7. Do SCPs restrict the management account?

No. SCPs apply to member accounts, not the management account.

8. What is OrganizationAccountAccessRole used for?

It allows authorized principals from the management account to assume an administrative role in a member account created through Organizations.

9. What two permissions are needed for cross-account role assumption?

The source identity needs permission to call sts:AssumeRole, and the target role’s trust policy must allow the source principal or account.

10. Why might an assumed administrative role fail to access the Organizations console?

Organizations administration is generally performed from the management account. The role can still have administrator permissions for services in the member account.

11. Why should workloads not be deployed in the management account?

The management account has special organization privileges and is not constrained by SCPs, increasing governance and blast-radius risks.

12. How does Control Tower relate to Organizations?

Control Tower builds governed multi-account environments using AWS Organizations along with account provisioning, controls, and landing-zone automation.

Practice Questions

Question 1

A company has created an AWS Organization and wants to prevent all production accounts from launching resources in unapproved AWS Regions. The security team attaches an SCP to the Production OU that denies actions outside the approved Regions. An administrator in the management account can still launch a resource in an unapproved Region. What explains this behavior?

A. SCPs only affect IAM users, not administrators.

B. SCPs cannot contain explicit deny statements.

C. SCPs do not restrict the management account.

D. The FullAWSAccess policy overrides the deny.

Correct answer: C

Explanation: SCPs apply to member accounts, including their IAM users and roles, but they do not restrict the management account. The test must be performed using a principal in a member account. An explicit deny would override an allow such as FullAWSAccess.

Question 2

A newly created member account contains an IAM role named OrganizationAccountAccessRole. An engineer in the management account tries to switch into it but receives AccessDenied. Which change is most appropriate?

A. Attach FullAWSAccess to the target account.

B. Grant the source identity permission to call sts:AssumeRole on the target role.

C. Attach an SCP granting AdministratorAccess.

D. Add the target account’s root user to the role’s trust policy.

Correct answer: B

Explanation: Cross-account assumption requires permission for the source identity to call sts:AssumeRole. The target role must also trust the source account or principal. SCPs do not grant permissions.

Question 3

An organization wants a policy that prevents developers in all nonproduction accounts from disabling AWS CloudTrail. The accounts are grouped in a NonProduction OU. What is the most scalable solution?

A. Add a deny statement to an SCP attached to the NonProduction OU.

B. Add a deny statement to an IAM policy in each developer role.

C. Rename all accounts with a NonProduction prefix.

D. Create a resource policy on the CloudTrail service.

Correct answer: A

Explanation: An SCP attached to the OU applies consistently to member accounts beneath it and can deny CloudTrail-management actions. The accounts’ IAM policies must still allow permitted actions, but they cannot bypass the SCP deny.

Question 4

A company needs to bring an existing AWS account into its organization without creating a new account. Which workflow should it use?

A. Create a new member account and merge the existing account’s resources automatically.

B. Invite the existing account to join the organization and have the account owner accept.

C. Create an OU using the existing account’s email address.

D. Assume OrganizationAccountAccessRole before the account joins.

Correct answer: B

Explanation: AWS Organizations can send an invitation to an existing account. The account owner must accept it. Creating a new account does not automatically migrate resources from another account.

Question 5

A solutions architect wants to validate whether a new SCP blocks ec2:RunInstances. The architect tests from the management account and successfully launches an instance. What should the architect do next?

A. Remove FullAWSAccess from the management account.

B. Test with a principal in a member account beneath the OU where the SCP is attached.

C. Attach the SCP directly to the AWS account root user.

D. Replace the SCP with an IAM permission boundary.

Correct answer: B

Explanation: SCPs do not restrict the management account. Testing must use an IAM principal in a member account governed by the SCP. The member account’s IAM policies must also grant ec2:RunInstances for the test to distinguish an SCP denial from a missing IAM allow.