While preparing for the AWS SAP-C02, many candidates get confused by the interaction between SCPs and IAM policies. In the real world, this is fundamentally a decision about Centralized Governance vs. Developer Velocity. Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Corp operates a multi-account AWS environment managed through AWS Organizations. The central security team has implemented Service Control Policies (SCPs) to enforce organizational guardrails across 47 AWS accounts grouped into various Organizational Units (OUs).
The security team created the following SCP and attached it to the “Development OU” containing account 2222-3333-4444:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsAllActions",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Sid": "DenyCloudTrail",
"Effect": "Deny",
"Action": "cloudtrail:*",
"Resource": "*"
}
]
}Development teams within account 2222-3333-4444 are now reporting they cannot create Amazon S3 buckets, even though their IAM policies explicitly grant s3:* permissions. The platform engineering team needs to resolve this issue without compromising the organization’s audit compliance posture.
Key Requirements #
Enable developers to perform standard S3 operations while maintaining centralized governance controls and CloudTrail protection.
The Options #
- A) Add an explicit “Allow” statement for
s3:CreateBucketto the SCP - B) Remove the account from the OU and attach the SCP directly to account
2222-3333-4444 - C) Instruct developers to add Amazon S3 permissions to their IAM entities
- D) Detach the SCP from account
2222-3333-4444
Correct Answer #
Option C - Instruct developers to add Amazon S3 permissions to their IAM entities.
Step-by-Step Winning Logic #
This question tests a fundamental AWS Organizations principle: SCPs define permission boundaries, not grant permissions.
The critical insight is understanding the AWS permission evaluation logic:
- SCPs act as guardrails - They define the maximum permissions available, but never grant permissions themselves
- The SCP in this scenario is NOT blocking S3 - It only denies CloudTrail operations
- The root cause is IAM-level - Developers lack proper IAM policy attachments
The SCP’s first statement "Action": "*" allows all actions (except CloudTrail), which means S3 operations are permitted at the SCP boundary level. The issue must be at the IAM identity level within the account.
Why this is the optimal solution:
- Cost: Zero infrastructure or policy changes required
- Security: Maintains the CloudTrail protection guardrail
- Operational simplicity: Follows AWS best practices for permission assignment
- Scalability: Reinforces proper IAM hygiene across the organization
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not Option A?
- Fundamental misunderstanding: SCPs with explicit “Allow” for specific services are redundant when
"Action": "*"already exists - Adding
s3:CreateBucketto the SCP changes nothing because SCPs don’t grant permissions - This reflects a common misconception that SCPs work like IAM policies
- Fundamental misunderstanding: SCPs with explicit “Allow” for specific services are redundant when
-
Why not Option B?
- Organizational anti-pattern: Moving accounts or changing SCP attachment points doesn’t solve IAM permission gaps
- Increases management complexity without addressing the root cause
- Violates the separation of concerns between organizational guardrails (SCP) and access grants (IAM)
-
Why not Option D?
- Security regression: Removes the CloudTrail protection control
- Violates compliance requirements for audit trail immutability
- Creates governance drift and potential regulatory exposure
- Classic example of “solving” symptoms by removing safety controls
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
OrgRoot[AWS Organization Root] --> DevOU[Development OU]
DevOU --> SCP[SCP: Allow * + Deny CloudTrail*]
SCP --> Account[Account 2222-3333-4444]
Account --> IAM[IAM User/Role]
IAM --> S3Policy[IAM Policy: s3:*]
SCP -->|Boundary Check| PermEval{Permission Evaluation}
S3Policy -->|Grant Check| PermEval
PermEval -->|Both Pass| Allowed[S3 Operation Allowed]
style SCP fill:#ff9999,stroke:#333,stroke-width:2px
style S3Policy fill:#99ff99,stroke:#333,stroke-width:2px
style PermEval fill:#ffcc99,stroke:#333,stroke-width:3px
style Allowed fill:#99ccff,stroke:#333,stroke-width:2px
Diagram Note: AWS evaluates permissions using an intersection model - both the SCP boundary and IAM grants must permit the action for it to succeed.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost Impact | Pros | Cons |
|---|---|---|---|---|
| A) Add S3 Allow to SCP | Low (5 min policy edit) | $0 (no infrastructure change) | Quick action, appears to address concern | Doesn’t actually solve the problem; demonstrates misunderstanding of SCP model; creates policy bloat |
| B) Restructure OU attachment | Medium (30 min + testing) | $0 (organizational change only) | May satisfy psychological need for “action” | Doesn’t address root cause; increases management overhead; same permission outcome |
| C) Fix IAM policies ✅ | Low-Medium (15 min per role/user) | $0 (configuration only) | Addresses actual root cause; reinforces proper IAM architecture; maintains security posture | Requires user education; may need multiple IAM entities updated |
| D) Remove SCP | Low (2 min detachment) | $0 direct / $15K-50K annually in potential compliance violations | Immediate unblocking of all operations | Removes audit protection; creates compliance gaps; violates security baseline; potential regulatory fines |
FinOps Critical Insight: While Option D has zero direct cost, the compliance risk exposure in regulated industries (HIPAA, PCI-DSS, SOC2) can trigger audit failures costing $15K-50K in remediation efforts, not including potential breach costs if CloudTrail is subsequently disabled.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the SAP-C02 exam, when you see SCP-related access issues, always verify IAM policies first. Remember: SCPs are guardrails that filter permissions, not grants that provide them. If an SCP allows an action (* or specific service), the problem is almost always at the IAM layer.
Real World #
In production environments, we encounter this scenario regularly during account onboarding. Our standard operating procedure includes:
- Pre-deployment SCP simulation: Using AWS IAM Policy Simulator to validate the intersection of SCPs and planned IAM policies before deployment
- Automated IAM policy templates: Infrastructure-as-Code (Terraform/CloudFormation) that provisions role-based access with pre-validated permissions
- Permission boundaries: Adding IAM permission boundaries as a second layer of defense, allowing developers self-service within defined limits
- Monitoring: CloudWatch metrics tracking
AccessDeniedAPI errors correlated with SCP vs. IAM causes
The hybrid approach: We typically implement a tiered SCP strategy:
- Root-level SCPs: Organization-wide denies (e.g., region restrictions, root account usage)
- OU-level SCPs: Workload-specific guardrails (e.g., prevent production data deletion)
- IAM policies + Permission Boundaries: Actual access grants with developer-safe boundaries
This creates defense-in-depth while maintaining developer velocity—something the exam question simplifies but real architecture demands.