AWS Solutions Architect Professional Training Course

At associate level an account is mostly a billing container. At professional level it is the strongest isolation boundary AWS gives you, and almost every Domain 1 scenario is decided by whether you put a boundary in the right place. Before you compare services, get the account model right, because the account model determines which services are even available as controls.

What an account actually isolates

An AWS account is a separate security principal space, a separate service-quota space, a separate blast radius, and a separate unit of billing. Two workloads in different accounts cannot reach each other's resources unless someone deliberately writes a cross-account trust. Two workloads in the same account share IAM, share most quotas, and share the consequences of a mistaken policy change.

That gives you four recurring reasons to split an account, and you should be able to name which one a scenario is invoking:

• Security isolation — a compromised principal in one account cannot enumerate or assume its way into another without an explicit trust.
• Blast radius — a bad deployment, a runaway job, or a deletion affects one environment only.
• Quota and limit isolation — a batch workload that consumes the account's Lambda concurrency or EC2 instance quota cannot starve production.
• Cost attribution — account-level charges need no tagging discipline to be accurate, which matters when tagging discipline is exactly what the organization lacks.

When a question offers "separate accounts" against "separate VPCs" or "separate IAM roles" for a requirement phrased as isolation, hard multi-tenancy, or regulatory separation, the account boundary is normally the answer. When the requirement is only network segmentation within one team's workload, a separate account adds operational overhead you were not asked to accept.

Organizations, organizational units, and the management account

AWS Organizations turns a set of accounts into one hierarchy with consolidated billing and centrally applied policy. The management account sits at the root; below it are organizational units (OUs), which can nest, and member accounts sit in exactly one OU or directly at the root.

Two rules about the management account come up constantly. First, service control policies do not restrict principals in the management account, so it must never host workloads — a scenario that describes production resources running in the management account is describing a finding, not a design. Second, the management account owns the billing relationship and the ability to create, invite, and remove accounts, so access to it should be a short list of humans using strong authentication and nothing else.

Design OUs around the policies you want to apply, not around the org chart. Reporting lines change every year; the set of controls that should apply to a production workload does not. A common shape is a Security OU, an Infrastructure OU, a Workloads OU containing per-environment child OUs, a Sandbox OU with permissive policy and hard spend limits, and a Suspended OU whose policy denies everything so a compromised or decommissioned account can be moved there instantly.

Delegated administration

Because the management account should stay empty, most organization-wide services support registering a member account as delegated administrator for that service. Security Hub, GuardDuty, Config, IAM Access Analyzer, Detective, Macie, Firewall Manager, and IAM Identity Center all follow this pattern: a security or audit account is registered once, and from then on it administers the service across every member account without anyone signing in to the management account.

In a scenario, the giveaway phrase is "without granting access to the management account" or "the security team must be able to." Delegated administration is nearly always the intended mechanism, and answers that route the security team through the management account are the near miss.

Trusted access and the services that need it

Organization-wide features — a CloudTrail organization trail, a Config aggregator, StackSets deployed to OUs, RAM sharing inside the organization — require trusted access to be enabled for that service in Organizations. Enabling it lets the service create service-linked roles in member accounts and act across them. This is why an organization trail can guarantee that a member account administrator cannot delete or stop logging: the trail is owned by the management account, and the member account sees it as read-only.

Feature sets and account lifecycle

Organizations supports consolidated billing only, or all features. Policy types such as service control policies require all features enabled, and moving from billing-only to all features requires every member account to accept the change. If a scenario says an organization cannot apply SCPs, an incomplete feature-set migration is a plausible cause.

Account creation should be automated rather than manual, because a hand-created account skips the baseline. Control Tower Account Factory, the Account Factory for Terraform pattern, and direct use of the CreateAccount API all achieve this; the design point is that a new account arrives already enrolled in the org trail, the Config aggregator, the guardrail policies, and the identity source. Closing accounts is slower than people expect and is subject to a rolling quota, so migration plans that assume instant teardown of hundreds of accounts need checking against current documented limits.

How this shows up on the exam

Domain 1 items rarely ask "what is an OU." They describe an enterprise with several business units, an audit requirement, a team that must not see another team's data, and a mandate to reduce operational overhead, then offer four workable designs. Rank them by asking: does this put the boundary at the account level where the requirement is isolation, does it keep the management account out of the operational path, does it apply the control once at an OU rather than repeatedly per account, and does it survive the creation of the next twenty accounts without manual work. The option that fails the last test is usually the one to eliminate first.