7.1.3. Organization Policies (SCPs, RCPs, Declarative Policies)
First Principle: Organization policies enforce security boundaries that no individual account can override. Different policy types operate at different levels — SCPs restrict what IAM principals can do, RCPs restrict what resources can accept, and declarative policies enforce service configurations.
Service Control Policies (SCPs):
- Restrict the maximum permissions available to IAM principals in member accounts
- Don't grant permissions — they only restrict
- Applied to OUs or accounts (not the management account)
- Common use: deny access to unused Regions, prevent disabling security services
Resource Control Policies (RCPs) — new in C03:
- Restrict what actions external principals can perform on resources in your organization
- Complement SCPs: SCPs control what your principals do; RCPs control what happens to your resources
- Use case: prevent external accounts from accessing your S3 buckets even if a bucket policy allows it
- Applied at the organization or OU level
Declarative Policies — new in C03:
- Enforce desired service configurations across all accounts
- Don't just block actions (like SCPs) — they enforce specific settings
- Example: enforce that all EC2 instances in the organization use IMDSv2
- Simpler than writing SCPs for configuration enforcement
AI Service Opt-Out Policies:
- Control whether AWS AI services can use your data for service improvement
- Applied at the organization level — ensures no account can individually opt in
- Required for organizations with strict data handling requirements
| Policy Type | What It Controls | Scope |
|---|---|---|
| SCP | What principals can DO | OU/Account (not management) |
| RCP | What can happen TO your resources | Organization/OU |
| Declarative | What configuration resources MUST have | Organization/OU |
| Tag policy | Required tag keys and values | Organization/OU |
| AI opt-out | AI service data usage | Organization/OU |
⚠️ Exam Trap: RCPs are new in C03 and complement SCPs. If a question asks about preventing external access to your resources even if resource policies allow it, RCPs are the answer. SCPs wouldn't help because the external principal isn't in your organization.
Scenario: An organization wants to ensure no S3 bucket in any account can be accessed by external principals, even if a developer accidentally adds a permissive bucket policy. An RCP at the organization level restricts resource access to principals within the organization only.
Reflection Question: How do RCPs close the gap that SCPs can't cover — specifically, controlling access FROM external principals?
