IAM & Governance Bundle

AWS IAM, IAM Access Analyzer, AWS Organizations, Service Control Policies (SCPs), Resource Control Policies (RCPs), and AWS Control Tower — the layers that decide WHO can do WHAT, WHERE the ceiling on that permission sits, and HOW a multi-account environment gets provisioned and kept compliant in the first place. This is the most heavily tested domain on the exam, and the SCP-vs-RCP distinction is the single freshest, sharpest trap in the entire 2024-2026 governance space.

Identity — primary role Governance — primary role Preventive — guardrails, not grants

Identity

SCPs cap principals

Resource

RCPs cap resources

7

RCP-supported services (and growing)

Nov 2025

Centralized Root Access Management GA

The Core Mental Model — Guardrails vs Grants

Six Tools, One Underlying Question: "What's the Ceiling, and Who Set It?"

IAM — the GRANTING layer. Identity-based policies (attached to users/roles/groups) and resource-based policies (attached to the resource itself) define what's actually ALLOWED for a specific principal. This is where permissions are positively granted.
IAM Access Analyzer — the VERIFICATION layer. Doesn't grant or restrict anything itself; it tells you what your existing policies actually allow — external access, internal access, and unused access — using automated reasoning (Zelkova) rather than simulation.
AWS Organizations — the STRUCTURAL layer. Groups accounts into OUs, enabling centralized policy-based governance across an entire multi-account environment instead of account-by-account configuration.
Service Control Policies (SCPs) — the IDENTITY-side ceiling. Sets the MAXIMUM permissions available to IAM principals (users/roles) in an account — SCPs never grant anything; they only restrict what IAM policies inside the account are even allowed to grant.
Resource Control Policies (RCPs) — the RESOURCE-side ceiling (new, late 2024+). Sets the MAXIMUM permissions on AWS RESOURCES in an account — restricting what resource-based policies (e.g. an S3 bucket policy) are allowed to grant, regardless of how permissive that resource policy is written.
AWS Control Tower — the PROVISIONING & ENFORCEMENT layer. Automates landing zone setup (account structure, baseline guardrails) on top of Organizations, deploying both preventive (SCP-based) and detective (Config-based) controls automatically across enrolled accounts.

⚠️ The Recurring Exam Theme

This domain is dominated by ONE distinction above all others now: SCPs cap what IDENTITIES (IAM principals) can be granted; RCPs cap what RESOURCES can grant via their resource-based policies — regardless of identity. A requirement like "no principal outside our organization should ever be able to access our S3 buckets, REGARDLESS of how a bucket policy is written" is the textbook RCP signal, and confusing it for an SCP (which can't reach resource-based policy permissiveness) is the single most common new trap in this space.

Exam Domain Mapping

Domain	Where This Bundle Shows Up
Identity & Access Management	The centerpiece — policy types, evaluation logic, Access Analyzer findings, root access management
Management & Security Governance	SCPs/RCPs, OU design, Control Tower guardrails, data perimeter construction
Security Logging & Monitoring	CloudTrail org trails, Access Analyzer unused-access dashboards, Control Tower drift detection
Threat Detection & Incident Response	Privileged root actions for emergency S3/SQS policy recovery, guided revocation workflows

Decision Tree — Mental Model

Threat

Over-permissioned IAM principals; resource-based policies accidentally exposing data externally; inconsistent security baselines across many accounts; standing, unmanaged root credentials in every member account

↓

Security Goal

Cap permissions at both the identity AND resource level, structure accounts for centralized governance, and eliminate unnecessary standing privileged access

↓

AWS Service

The IAM & Governance Bundle

IAM — grants permissions Access Analyzer — verifies actual access Organizations — structures accounts SCPs — identity-side ceiling RCPs — resource-side ceiling Control Tower — provisions + enforces

↓

Implementation

Deploy Control Tower for landing zone baseline; layer SCPs and RCPs at the OU level for both identity and resource ceilings; enable Access Analyzer org-wide; centralize root access management.

↓

Monitoring

Access Analyzer dashboards for external/internal/unused access; Control Tower drift detection; CloudTrail organization trail for all governance-relevant API activity.

↓

Remediation

Guided revocation of unused permissions; privileged root actions to recover a misconfigured S3/SQS deny-all policy without using member-account root credentials; Control Tower Reset to repair governance drift.

Final Summary

Must Memorize

SCPs cap IDENTITIES (IAM principals); RCPs cap RESOURCES (resource-based policies) — different sides of the same ceiling concept
Neither SCPs nor RCPs ever GRANT permissions — both are restriction-only, requiring an actual IAM/resource policy underneath to grant anything in the first place
RCPs don't take effect on the management account (mirrors the SCP exemption pattern)
Centralized Root Access Management (GA Nov 2025) lets you remove standing root credentials and perform privileged root actions (e.g. S3/SQS deny-all policy recovery) from the management/delegated account
Control Tower's Controls Dedicated experience (Nov 2025) lets you adopt managed controls WITHOUT a full landing zone

Must Understand

Why IAM Access Analyzer uses automated reasoning (provable correctness) rather than simulation/testing
The OU-level policy inheritance model shared by SCPs, RCPs, and declarative policies
The distinction triangle: SCPs (identity ceiling) vs RCPs (resource ceiling) vs IAM policies (actual grant)

Can De-prioritize

Exact Control Tower landing zone version numbers
Console UI navigation specifics
Full list of every RCP-supported service (know the pattern, not the exhaustive roster)

Exam appearance probability: HIGH

Core Services — Deep Dive

IAM Core Concepts The granting layer

Identity-based policiesAttached to a user, group, or role — define what THAT PRINCIPAL can do

Resource-based policiesAttached to the resource itself (e.g. S3 bucket policy, KMS key policy) — define who can access THAT RESOURCE, including across accounts

Permission boundariesAn identity-based policy attached to a user/role that sets the MAXIMUM permissions that identity can ever have — even if other attached policies grant more

Policy evaluation logicExplicit DENY always wins; absent an explicit allow, the default is implicit deny; SCPs/RCPs/permission boundaries all act as additional ceilings evaluated alongside identity/resource policies

The full evaluation logic for a request inside an Organization: SCP allow? → RCP allow? → permission boundary allow? → identity/resource policy allow? Every applicable layer must allow (and none may explicitly deny) for the request to succeed.

IAM Access Analyzer Verification, not enforcement

External access findingsIdentifies resource-based policies granting access to a principal OUTSIDE your defined zone of trust (an account or organization)

Internal access findingsIdentifies which principals WITHIN your zone of trust have access to specific, selected business-critical resources

Unused access findingsIdentifies unused IAM roles, unused access keys/passwords, and unused service/action-level permissions on active roles, based on CloudTrail-derived last-accessed data

Policy checksBasic and custom policy validation BEFORE deployment — e.g. checking a proposed policy doesn't grant public access or access to a specific critical resource — usable in a CI/CD pipeline

Underlying technologyAutomated reasoning (the Zelkova engine) — mathematically proves what a policy allows, rather than testing/simulating individual requests

Guided revocation gives developers step-by-step instructions to remove unused roles, unused permissions, unused access keys, or unused passwords — closing the loop from finding to fix.
External access findings are free; unused access analyzers are billed per IAM role/user analyzed per analyzer per month.
External access analysis is REGIONAL (create one per Region to cover all resources); unused access findings do NOT vary by Region — one analyzer covers your whole scope regardless of where you create it.
"Validate that a newly authored IAM policy doesn't accidentally grant public access, as part of our CI/CD pipeline, before it's ever deployed" → Access Analyzer custom policy checks.

AWS Organizations The structural layer

What it doesGroups multiple AWS accounts into a single organization with hierarchical Organizational Units (OUs), enabling centralized policy attachment and consolidated billing

Policy typesSCPs, RCPs, declarative policies (EC2/VPC/EBS configuration), backup policies, tag policies, AI services opt-out policies, chat applications policies, Security Hub policies, upgrade rollout policies

InheritancePolicies attached to a root or OU apply to every account beneath it in the hierarchy; an account can have multiple policies of the same type applied at different levels simultaneously

Declarative policies (newer policy type) let you centrally declare and enforce a DESIRED CONFIGURATION for a service (e.g. EC2 settings) across the organization — once attached, the configuration is automatically maintained even as the service adds new features/APIs, unlike SCPs which only restrict actions rather than enforcing a specific configuration state.

Service Control Policies (SCPs) Identity-side ceiling

What it capsThe maximum permissions available to IAM principals (users and roles) within an account — not the management account, which is exempt

Grants permissions?NEVER — SCPs only restrict; an explicit IAM allow is still required underneath for anything to actually be permitted

Strategy typesAllow-list (deny everything by default, explicitly allow specific services/actions) or deny-list (allow everything by default, explicitly deny specific dangerous actions)

Classic use case: "prevent any IAM principal in this OU from ever disabling CloudTrail or deleting the centralized logging bucket, regardless of what IAM permissions they're individually granted."
Even an account's root user is constrained by SCPs (outside the exempt management account) — this is a frequently tested point, since many people assume root is always unrestricted.

Resource Control Policies (RCPs) High — newest major governance addition

IntroducedNovember 2024 — at launch, supported S3, STS, KMS, SQS, and Secrets Manager

What it capsThe maximum permissions on AWS RESOURCES within an account — restricting what a resource-based policy (e.g. an S3 bucket policy) is allowed to grant, REGARDLESS of how permissive that bucket policy is written

Grants permissions?NEVER — same restriction-only model as SCPs, just applied to the resource side instead of the identity side

Service expansion timelineECR and OpenSearch Serverless added June 2025; Cognito and CloudWatch Logs added January 2026 — the supported-service list is actively growing

Regional availabilityAll AWS commercial Regions at launch; expanded to AWS GovCloud (US) Regions in May 2025

The textbook RCP use case: "no principal outside my organization can access S3 buckets in my organization" — enforced centrally and consistently REGARDLESS of what any individual bucket policy says, closing the classic "someone wrote an overly permissive bucket policy" gap that SCPs structurally cannot reach (SCPs only constrain identities, never resource-based policy content).
RCPs complement SCPs to build a comprehensive data perimeter — SCPs constrain what your identities can do; RCPs constrain what your resources can be configured to allow, together covering both directions of unauthorized access.
Like SCPs, RCPs do NOT take effect on the management account, and there's a default RCPFullAWSAccess managed policy automatically attached everywhere (root, every OU, every account) when RCPs are enabled — it allows all principals/actions to pass through RCP evaluation by default until you build more restrictive RCPs yourself, and it cannot be detached.
IAM Access Analyzer can be used to review the IMPACT of a proposed RCP on existing resource permissions before you commit to it.

Centralized Root Access Management High — exam-fresh, GA Nov 2025

What it doesLets the management account (or a designated delegated administrator account) centrally manage, monitor, and remove standing root credentials across member accounts — and perform specific privileged root actions WITHOUT needing the member account's own root credentials

Two components(1) Root credential management — centrally monitor/remove/disallow recovery of long-term root credentials; (2) Privileged root actions — scoped, task-specific root sessions for specific operations like restoring access to an S3 bucket or SQS queue with an accidental deny-all policy

New account defaultNew accounts created in the organization can have NO root credentials by default once this feature is properly configured

The forcing functionBeginning Spring 2025, organizations that have NOT enabled centralized root access management are required to register MFA for member account root users to access the console at all

This builds on AWS's broader root-security push: MFA required for management account root users starting May 2024, FIDO2 passkey support added June 2024, and finally centralized management itself in late 2025.
"Recover access to an S3 bucket that was accidentally locked out by an overly restrictive deny-all bucket policy, without using that member account's own root user credentials" → privileged root actions via centralized root access management.
Adoption is gradual and non-disruptive — enabling the feature doesn't immediately strip existing accounts of root credentials; specific actions (like deleting root credentials) must still be deliberately taken per account.

AWS Control Tower Provisioning + automated enforcement

What it doesAutomates the setup of a well-architected, multi-account "landing zone" on top of Organizations — recommended OU structure, shared accounts (Log Archive, Audit/Security), IAM Identity Center integration, baseline guardrails

Mandatory vs optional controlsMandatory controls are always applied by Control Tower automatically; optional controls are self-selected based on the organization's own needs

Preventive vs detective controlsPreventive controls are implemented as SCPs (stop the action before it happens); detective controls are powered by AWS Config rules (flag non-compliant resources after the fact)

Account FactoryAutomates provisioning of new, pre-configured accounts into the governed landing zone

Controls Dedicated experience / Control Only Experience (Nov 2025) — lets organizations with an ALREADY-ESTABLISHED, well-architected multi-account environment adopt AWS managed controls WITHOUT implementing a full landing zone from scratch. Previously, using Control Tower's controls required the full landing zone setup; this removes that barrier for mature environments.
Landing zone version 4.0 changed the organization structure: Control Tower no longer creates a dedicated, separate Security OU — instead, the OU containing the service integration accounts itself becomes the designated Security OU. The Control Tower Baseline and Config Baseline don't apply to this Security OU (expected "Not Applicable" status).
Drift correction: a landing zone "Update" resolves most drift; "Reset" (available on landing zone 3.1+) is the most thorough way to repair drift when an Update alone isn't sufficient.
Now available in the European Sovereign Cloud (January 2026), reflecting AWS's broader sovereign-cloud expansion.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

No principal outside the organization should EVER access our S3 buckets, regardless of how any individual bucket policy is written

regardless of resource policydata perimeterexternal principal

Expected Answer

Resource Control Policy (RCP)

Distractor	Why it's wrong
Service Control Policy (SCP)	SCPs constrain IDENTITIES (your own principals' actions), not what a resource-based policy is allowed to grant to an external principal — structurally cannot enforce this
S3 bucket policy alone	Relies on every individual bucket policy being written correctly forever — exactly the inconsistency RCPs are designed to centrally eliminate

Prevent any IAM principal in an OU from ever disabling CloudTrail, regardless of their individually granted IAM permissions

cap identity permissionsorg-wide guardrail

Expected Answer

Service Control Policy (SCP)

Distractor	Why it's wrong
Resource Control Policy (RCP)	RCPs cap what resources can grant via resource-based policy, not the action-level permissions of IAM principals — wrong side of the ceiling
IAM permission boundary on every role individually	Doesn't scale across an entire OU and is easy to miss on a newly created role — SCPs apply centrally and automatically

Validate that a newly written IAM policy doesn't accidentally grant public access, as part of a CI/CD pipeline before deployment

policy validationbefore deploymentCI/CD

Expected Answer

IAM Access Analyzer custom policy checks

Distractor	Why it's wrong
AWS Config rule	Evaluates DEPLOYED resource configuration, not a policy document before it's ever deployed

Identify IAM roles that have permissions they haven't actually used in 90+ days, to support least-privilege cleanup

unused permissionsleast privilege

Expected Answer

IAM Access Analyzer unused access findings

Distractor	Why it's wrong
CloudTrail alone	Provides the raw last-accessed data Access Analyzer consumes, but doesn't itself generate the structured unused-access findings/dashboard

Recover access to an S3 bucket accidentally locked by a deny-all bucket policy, without using that member account's own root credentials

locked outdeny-all policy recoveryno member account root

Expected Answer

Centralized Root Access Management — privileged root actions

Distractor	Why it's wrong
Log into the member account as root	Exactly what this feature is designed to make unnecessary, and many organizations using this feature won't even have standing root credentials to log in with anymore

Adopt AWS Control Tower's managed guardrails on an already well-architected, established multi-account environment without rebuilding it as a full landing zone

already establishedno full landing zonemanaged controls only

Expected Answer

Control Tower Controls Dedicated (Control Only) experience

Distractor	Why it's wrong
Implement a full Control Tower landing zone from scratch	Unnecessarily disruptive — forces re-architecting an environment that's already well-architected, exactly what the newer Controls Dedicated experience was introduced to avoid

Integrations

AWS CloudTrail

WhatSource of last-accessed data powering IAM Access Analyzer's unused access findings; Control Tower can manage an organization-level trail as part of the landing zone

AWS Config

WhatPowers Control Tower's detective controls, evaluating deployed resource configuration against the landing zone's baseline

IAM Identity Center

WhatControl Tower automates IAM Identity Center group/permission-set configuration for governed account access (or you can choose to self-manage access instead)

Amazon S3 / STS / KMS / SQS / Secrets Manager / ECR / OpenSearch Serverless / Cognito / CloudWatch Logs

WhatThe growing list of services where RCPs can centrally restrict resource-based policy permissiveness

CI/CD pipelines

WhatIAM Access Analyzer's custom policy checks can be invoked via CLI/API as a pipeline gate, blocking deployment of policies that fail validation

Delegated Administrator Accounts

WhatCentralized Root Access Management supports an optional delegated administrator account that can manage root access without requiring direct access to the management account itself

Costs, Limits & Quotas

Pricing Model

IAM, Organizations, SCPs, RCPsNo direct charge — these are foundational, free governance constructs

IAM Access Analyzer — external/internal accessFree

IAM Access Analyzer — unused accessBilled per IAM role/user analyzed, per analyzer, per month

Control TowerNo direct charge for Control Tower itself — you pay for the underlying resources it provisions/manages (Config, CloudTrail, S3, etc.)

Common Cost Mistakes

Creating redundant unused-access analyzers across many Regions when unused access findings don't actually vary by Region (only external access findings are region-scoped)
Requiring a full Control Tower landing zone migration for a mature environment that only needed managed controls, when Controls Dedicated would have sufficed

Cost Optimization

Create one unused-access analyzer rather than one per Region, since unused access findings are Region-independent
Use Control Tower's Controls Dedicated experience for already-established environments instead of a full landing zone rebuild

Limits & Quotas

Org policy tagsUp to 50 tags per organization policy

SCP/RCP scopeNeither takes effect on the management account

Access Analyzer external accessRegional — create one analyzer per Region to cover all resources in that Region

Control Tower landing zone versionsReset operation requires landing zone version 3.1 or newer; earlier versions are not compatible with Reset

⚠️ Exam trap

RCPs have a default RCPFullAWSAccess managed policy automatically attached to the root, every OU, and every account the moment RCPs are enabled — and it CANNOT be detached. This means simply "enabling RCPs" changes nothing on its own; you must author and attach your own more-restrictive RCPs for any actual effect, mirroring the analogous SCP default-allow behavior.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know

SCPs cap identities; RCPs cap resources — neither grants anything, both only restrict
RCPs and SCPs both exempt the management account
Centralized Root Access Management eliminates standing root credentials and enables scoped privileged root actions
Control Tower preventive controls = SCPs; detective controls = Config rules
Controls Dedicated experience lets mature environments adopt managed controls without a full landing zone

Good Practice

Layer SCPs and RCPs together to build a comprehensive data perimeter covering both identity and resource sides
Enable IAM Access Analyzer org-wide for external, internal, and unused access visibility
Use custom policy checks in CI/CD to catch overly permissive policies before deployment
Centralize root access management and require MFA for any remaining standing root credentials

Advanced Practice

Use Access Analyzer's "review RCP impact" capability before committing a new RCP organization-wide
Use guided revocation workflows to operationalize least-privilege cleanup at scale
Design OU structure anticipating both SCP and RCP inheritance, not just SCPs alone, given RCPs are newer and easy to overlook in legacy architecture diagrams

9 — Common Exam Traps

Misconception	Reality
"SCPs can restrict what a resource-based policy is allowed to grant"	False — SCPs only constrain IAM principals (identity-side); only RCPs constrain resource-based policy permissiveness
"SCPs/RCPs can grant additional permissions beyond what IAM policies allow"	False — both are restriction-only ceilings; an explicit underlying IAM/resource policy allow is always still required
"The root user is always fully unrestricted, even with SCPs in place"	False outside the exempt management account — SCPs constrain the root user just like any other principal in member accounts
"Enabling RCPs immediately restricts resource permissions org-wide"	False — the default RCPFullAWSAccess managed policy (which cannot be detached) allows everything to pass through until you author your own more-restrictive RCPs
"Using Control Tower's managed controls always requires implementing a full landing zone"	Outdated since November 2025 — the Controls Dedicated (Control Only) experience lets established environments adopt managed controls without a full landing zone rebuild

Lookalike Comparisons

Comparison	What actually differs
SCPs vs RCPs	Identity-side maximum permissions (constrains your principals) vs resource-side maximum permissions (constrains what your resources' policies can grant) — two halves of a complete data perimeter
SCPs vs IAM permission boundaries	Org-wide, OU-level, applies automatically to every principal in scope vs attached individually per user/role — SCPs scale centrally, boundaries are per-identity
IAM Access Analyzer vs AWS Config	Uses automated reasoning to PROVE what a policy allows (access/permission analysis) vs evaluates deployed resource CONFIGURATION against rules — different analytical techniques and different questions entirely
Declarative policies vs SCPs	Enforce a specific desired CONFIGURATION STATE for a service (e.g. EC2 settings), automatically maintained as the service evolves, vs restrict which ACTIONS are permitted — configuration enforcement vs action restriction
Control Tower preventive vs detective controls	SCP-based, stops the action before it happens vs Config-based, flags non-compliant resources after they already exist

Flashcards — 19 Cards

Click card to flip. Mark right or wrong to track score.

Click to reveal answer

1 / 19

Mark: Score: 0/0

Practice Quiz — 9 Questions

SCS-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.

out of 9 correct