AWS Organizations & Multi-Account Governance
By Pritesh Yadav 16 min read —
AWS Organizations lets you centrally manage many AWS accounts under one roof, share a single bill, and apply guardrails. The most-tested ideas are that consolidated billing combines usage to unlock volume discounts and share Reserved Instances/Savings Plans, that Service Control Policies (SCPs) set the maximum allowed permissions but never grant any, and that the management (payer) account sits at the top. Control Tower automates setting up a secure, multi-account landing zone on top of Organizations.
Most confused here: SCP = a permission ceiling/guardrail that never grants access (IAM still grants); Organizations = account & billing management, not identity; Control Tower = automated landing-zone setup on top of Organizations; consolidated billing = one bill + pooled volume pricing + shared RIs/Savings Plans.
Q1 A company attaches a Service Control Policy (SCP) to an Organizational Unit that explicitly allows full S3 access. A user in an account under that OU still cannot read any S3 buckets. What is the most likely reason?
- SCPs do not grant permissions; the user still needs an IAM policy that allows the S3 actions
- The SCP must be attached to the management account instead of the OU
- Consolidated billing must be enabled before SCPs take effect
- S3 access can only be controlled through bucket policies, never through SCPs
Answer: A
Why A is correct: An SCP only sets the maximum permissions an account can use (a guardrail/ceiling). It never grants anything by itself. The user still needs an IAM policy in their account that actually allows the S3 actions. The SCP simply doesn't block them.
Why the other options are wrong:
- B — SCPs are meant to be attached to OUs or accounts to scope member accounts; attaching to the management account would not fix a missing IAM grant (and SCPs don't restrict the management account anyway).
- C — Consolidated billing is about combining charges, not about activating policy enforcement.
- D — SCPs can absolutely affect S3 actions as a ceiling; the limitation is that they grant nothing, not that they ignore S3.
Common trap: Candidates think an "Allow" SCP hands out access. SCPs filter what IAM is allowed to grant; they are a ceiling, never a key.
Q2 A business runs 12 AWS accounts and wants one invoice plus pricing benefits where the combined usage of all accounts counts toward volume discount tiers. Which AWS Organizations feature delivers this?
- Service Control Policies
- Consolidated billing
- AWS Control Tower
- Tag policies
Answer: B
Why B is correct: Consolidated billing produces a single bill for all member accounts and aggregates their usage so the total crosses tiered/volume-pricing thresholds faster, which can lower the overall cost.
Why the other options are wrong:
- A — SCPs are permission guardrails; they have nothing to do with billing or discounts.
- C — Control Tower automates setting up a governed multi-account environment, but the pooled-usage discount itself comes from consolidated billing.
- D — Tag policies standardize resource tags for organization and cost allocation; they do not aggregate usage for volume pricing.
Common trap: People credit Control Tower for the cost savings. The discount aggregation is a consolidated-billing capability that exists in Organizations even without Control Tower.
Q3 One account in an organization purchases a Reserved Instance but only uses part of it. With default settings, what happens to the unused portion across the organization?
- The unused portion expires immediately and cannot be reclaimed
- It can only be used by the management account, never member accounts
- The discount can be shared and applied to matching usage in other accounts under consolidated billing
- It is automatically converted into a Savings Plan for the whole organization
Answer: C
Why C is correct: Under consolidated billing, Reserved Instance and Savings Plan discounts are shared across all accounts in the organization by default. If one account doesn't fully use its RI, the benefit can apply to matching usage in another account, reducing waste.
Why the other options are wrong:
- A — The benefit isn't lost; sharing is exactly the mechanism that prevents waste.
- B — Sharing flows across member accounts, not just the management account.
- D — RIs and Savings Plans are separate commitment types; AWS does not auto-convert one into the other.
Common trap: Assuming RIs are locked to the buying account. By default they are shared org-wide, which is a key consolidated-billing exam point.
Q4 A new cloud team wants to quickly stand up a secure, pre-configured multi-account environment with a landing zone, baseline guardrails, and centralized logging without manually wiring everything. Which AWS service is purpose-built for this?
- AWS IAM Identity Center
- AWS Config
- AWS Systems Manager
- AWS Control Tower
Answer: D
Why D is correct: AWS Control Tower automates the setup of a well-architected, multi-account "landing zone" on top of AWS Organizations, applying recommended guardrails, account provisioning (Account Factory), and centralized logging out of the box.
Why the other options are wrong:
- A — IAM Identity Center manages workforce sign-in and access, not the overall account landing zone.
- B — AWS Config records and evaluates resource configuration compliance; it's a piece Control Tower uses, not the full setup tool.
- C — Systems Manager handles operational management of resources, not multi-account governance setup.
Common trap: Confusing Control Tower (sets up and governs the whole multi-account structure) with Config (just monitors configuration compliance within accounts).
Q5 Which statement best describes the relationship between AWS Organizations and AWS IAM?
- Organizations manages accounts and sets permission boundaries with SCPs, while IAM grants the actual permissions within each account
- Organizations replaces IAM and grants user permissions directly
- IAM manages the organization structure and Organizations issues user credentials
- They are the same service marketed under two names
Answer: A
Why A is correct: Organizations operates at the account level (grouping accounts into OUs, billing, and SCP guardrails). IAM operates inside each account to grant specific permissions to users and roles. SCPs set the ceiling; IAM does the actual granting within that ceiling.
Why the other options are wrong:
- B — Organizations never grants user permissions; that is always IAM's job.
- C — This reverses their roles; IAM does not manage org structure and Organizations does not issue user credentials.
- D — They are distinct services with different scopes.
Common trap: Treating SCPs as a substitute for IAM. Effective permission = the overlap of what IAM allows AND what the SCP allows.
Q6 A company wants all member accounts grouped by function — production, development, and security — so it can apply different guardrails to each group at once. Which Organizations feature should it use?
- Tag policies
- Organizational Units (OUs)
- Cost allocation tags
- Resource groups
Answer: B
Why B is correct: Organizational Units are containers that group accounts so policies like SCPs can be applied to an entire group at once. Putting production accounts in one OU and dev accounts in another lets you govern each set with different guardrails efficiently.
Why the other options are wrong:
- A — Tag policies standardize how resources are tagged; they do not group accounts for policy attachment.
- C — Cost allocation tags organize billing data, not account grouping for guardrails.
- D — Resource groups organize resources within an account, not accounts within an organization.
Common trap: Mixing up OUs (groups of accounts) with resource groups (groups of resources inside one account).
Q7 In an AWS Organization, which statement about the management (payer) account is correct?
- SCPs attached at the root restrict the management account just like member accounts
- It must be the account with the highest monthly usage
- It receives the consolidated bill for all member accounts and creates/manages the organization
- Each member account also receives its own separate invoice from AWS
Answer: C
Why C is correct: The management account (also called the payer account) creates the organization, invites or creates member accounts, and pays the single consolidated bill that covers all member accounts' charges.
Why the other options are wrong:
- A — SCPs do not restrict the management account, even when attached at the root; it always retains full control.
- B — Usage level has nothing to do with which account is the management account.
- D — Member accounts do not get separate AWS invoices; charges roll up to the payer account.
Common trap: Believing SCPs can lock down the management account. They cannot — a key reason to run no production workloads there.
Q8 A security team wants to guarantee that no account in the organization can launch resources in any AWS Region except us-east-1 and eu-west-1, regardless of what local IAM admins try. Which approach achieves this guardrail?
- Add an IAM policy in each account denying other Regions
- Enable a tag policy requiring a Region tag
- Use cost allocation tags to track Region usage
- Apply a Service Control Policy that denies actions outside the allowed Regions
Answer: D
Why D is correct: An SCP applies an organization-wide ceiling that even account-level IAM admins cannot override. Denying actions outside allowed Regions in an SCP enforces the restriction across every member account no matter what IAM policies say locally.
Why the other options are wrong:
- A — Local IAM policies can be changed by account admins, so they don't guarantee an org-wide restriction.
- B — Tag policies enforce tag formatting, not which Regions can be used.
- C — Cost allocation tags only help report spending; they enforce nothing.
Common trap: Reaching for IAM for an org-wide mandate. Only SCPs create a ceiling that member-account admins cannot lift.
Q9 A finance manager wants consistent, correctly formatted tags (for example, all resources tagged with a "CostCenter" key in a standard format) enforced across accounts so cost reports are reliable. Which feature is designed for this?
- Tag policies
- Service Control Policies
- Organizational Units
- AWS Budgets
Answer: A
Why A is correct: Tag policies in AWS Organizations define standardized tag keys and value formats and report on non-compliant resources, helping keep tagging consistent across accounts so cost allocation and reporting stay accurate.
Why the other options are wrong:
- B — SCPs control allowed actions, not tag formatting standards.
- C — OUs group accounts; they don't define tag standards.
- D — AWS Budgets alerts you when spending crosses thresholds; it doesn't enforce tag formats.
Common trap: Confusing tag policies (standardize tag formatting org-wide) with cost allocation tags (mark tags as usable in billing reports). They work together but are different things.
Q10 Why is using a multi-account strategy (separate accounts for prod, dev, and test) often considered a best practice instead of putting everything in one account?
- It is the only way to get internet access for workloads
- It provides strong isolation of resources, separate billing visibility, and a smaller blast radius if one account is compromised
- It removes the need for IAM permissions entirely
- It automatically makes every workload highly available across Regions
Answer: B
Why B is correct: Separate accounts create hard boundaries between environments, so a problem or breach in one account is contained (smaller blast radius). It also makes per-environment cost tracking and policy control much cleaner.
Why the other options are wrong:
- A — Internet access has nothing to do with the number of accounts.
- C — You still need IAM inside every account to grant permissions.
- D — High availability comes from architecture (Multi-AZ/Region design), not from splitting accounts.
Common trap: Thinking more accounts magically add availability. The benefit is isolation, governance, and billing clarity — not automatic resilience.
Q11 A developer's IAM policy in a member account allows EC2 actions, but an SCP attached to the account's OU does not include EC2 in its allowed actions. What is the effective result for the developer?
- EC2 actions are allowed because IAM overrides SCPs
- EC2 actions are allowed only in the management account
- EC2 actions are denied because the SCP ceiling does not permit them
- EC2 actions are allowed but billed at a higher rate
Answer: C
Why C is correct: A permission only works if BOTH the SCP allows it AND IAM grants it. Since the SCP ceiling excludes EC2, the action is blocked no matter what the IAM policy says. The SCP wins as the upper limit.
Why the other options are wrong:
- A — IAM never overrides an SCP; the SCP is the ceiling IAM must stay under.
- B — The management account isn't relevant to a member-account developer's access here.
- D — SCPs affect permissions, not pricing.
Common trap: Forgetting that effective access is the intersection of SCP and IAM. If either one says no, the action is denied.
Q12 Which scenario correctly describes a benefit a company gains purely from enabling consolidated billing in AWS Organizations?
- It automatically encrypts all data across member accounts
- It blocks risky API actions across the organization
- It provisions new accounts with built-in guardrails automatically
- Combined data-transfer and tiered usage across accounts can reach lower per-unit pricing than each account alone
Answer: D
Why D is correct: Consolidated billing aggregates usage from all accounts, so combined volume can cross tiered-pricing thresholds and qualify for lower per-unit rates than each account would reach on its own — plus a single, simpler bill.
Why the other options are wrong:
- A — Billing does not encrypt data; encryption is a separate service-level setting.
- B — Blocking API actions is the job of SCPs, not billing.
- C — Automatic account provisioning with guardrails is a Control Tower (Account Factory) feature.
Common trap: Attributing security or governance outcomes to consolidated billing. Its benefits are cost aggregation and one bill — nothing about permissions or encryption.
Q13 A company asks which service it should use to centrally manage workforce user sign-in and assign access across many AWS accounts in its organization. Which service fits best?
- AWS IAM Identity Center
- AWS Organizations alone
- Service Control Policies
- AWS Control Tower guardrails
Answer: A
Why A is correct: AWS IAM Identity Center provides centralized single sign-on and lets administrators assign users and groups access to multiple accounts in the organization from one place, including connecting to an external identity source.
Why the other options are wrong:
- B — Organizations manages accounts and billing but is not a sign-in/identity assignment tool by itself.
- C — SCPs set permission ceilings; they don't manage user sign-in.
- D — Control Tower guardrails enforce policy baselines, not centralized user authentication.
Common trap: Assuming Organizations handles user logins. Account/billing management (Organizations) and workforce identity/SSO (IAM Identity Center) are different jobs.
Q14 A company already uses AWS Organizations with SCPs. It now wants automated account provisioning, pre-built guardrails, and a dashboard to monitor compliance across accounts with minimal manual setup. What is the most accurate way to describe how Control Tower relates to Organizations here?
- Control Tower replaces Organizations and the company must delete its existing organization
- Control Tower sits on top of Organizations and adds automated setup, guardrails, and a governance dashboard
- Control Tower and Organizations are unrelated and cannot be used together
- Control Tower only manages billing, while Organizations only manages security
Answer: B
Why B is correct: Control Tower is built on top of AWS Organizations. It uses Organizations (plus Config, IAM Identity Center, and others) under the hood and adds automated landing-zone setup, prebuilt guardrails, Account Factory provisioning, and a compliance dashboard.
Why the other options are wrong:
- A — Control Tower uses Organizations; it doesn't replace or require deleting it.
- C — They are tightly related — Control Tower depends on Organizations.
- D — Neither description is accurate; Control Tower governs the multi-account environment broadly, not just billing.
Common trap: Viewing Control Tower and Organizations as competitors. Control Tower is an automation/governance layer that runs on Organizations.
Q15 Which statement about Service Control Policies (SCPs) is TRUE?
- SCPs grant permissions to IAM users when attached to an account
- SCPs only work in the management account and ignore member accounts
- SCPs apply to the root user of member accounts and define the maximum available permissions, but grant nothing
- SCPs are used to allocate Reserved Instances between accounts
Answer: C
Why C is correct: SCPs define the maximum set of permissions available in member accounts — and that ceiling even constrains the member account's root user. However, they only filter what can be allowed; they never grant permissions on their own.
Why the other options are wrong:
- A — SCPs grant nothing; IAM does the granting within the SCP ceiling.
- B — SCPs apply to member accounts/OUs; the management account is the one they do not restrict.
- D — RI sharing is a consolidated-billing feature, unrelated to SCPs.
Common trap: Many forget SCPs can even limit a member account's root user — yet still grant zero permissions themselves.
Q16 An organization sees that combined Savings Plans commitments are being applied across several member accounts automatically, lowering total cost. A manager wants to confirm which mechanism enables this sharing. What is the correct answer?
- Tag policies pooling commitments across accounts
- Service Control Policies enabling discount transfers
- Control Tower guardrails redistributing commitments
- Consolidated billing sharing Savings Plans and Reserved Instance benefits across accounts
Answer: D
Why D is correct: Just like Reserved Instances, Savings Plans benefits are shared across all accounts in the organization through consolidated billing by default, so unused commitment in one account can apply to matching usage in another, lowering the total bill.
Why the other options are wrong:
- A — Tag policies standardize tags; they have no role in commitment sharing.
- B — SCPs are permission guardrails, not billing mechanisms.
- C — Control Tower governs account setup and compliance, not discount pooling.
Common trap: Thinking Savings Plan sharing needs special configuration. It rides on consolidated billing automatically, the same way RI sharing does.