While preparing for the AWS SAP-C02, many candidates get confused by the difference between IAM policies, permission boundaries, and Service Control Policies (SCPs). In the real world, this is fundamentally a decision about centralized governance vs. operational complexity. The question isn’t just ‘Can we restrict access?’ but ‘Can we prevent privilege escalation while maintaining auditability?’ Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Inc. is a multinational e-commerce company using AWS Organizations with a fully-featured multi-account structure. The company has 47 AWS accounts organized into Organizational Units (OUs) by department: Development, Production, Shared Services, and Security.
The Procurement Operations team wants to enable software engineers to self-service approved third-party tools from AWS Marketplace while maintaining strict financial controls. They’ve decided to use AWS Private Marketplace to create an allow-list of approved software products.
The company has established a shared services account in each OU where the procurement manager operates. The procurement manager uses an IAM role named procurement-manager-role to curate the Private Marketplace catalog.
Key Requirements #
Design an access control architecture that:
- Allows only the
procurement-manager-roleto administer the Private Marketplace - Prevents all other principals (including account administrators, developers, and other IAM entities) from modifying the Private Marketplace configuration
- Prevents unauthorized creation of roles with the same name to bypass controls
- Minimizes operational overhead across 47 accounts
The Options #
-
A) Create an IAM role named
procurement-manager-rolein all AWS accounts; attach thePowerUserAccessmanaged policy to this role; apply inline policies to all IAM users and roles in every account to deny permissions associated withAWSPrivateMarketplaceAdminFullAccess. -
B) Create an IAM role named
procurement-manager-rolein all AWS accounts; attach theAdministratorAccessmanaged policy to this role; define a permissions boundary containingAWSPrivateMarketplaceAdminFullAccessand attach it to all developer roles. -
C) Create an IAM role named
procurement-manager-rolein all shared services accounts; attach theAWSPrivateMarketplaceAdminFullAccessmanaged policy to this role; create an SCP at the organization root that denies Private Marketplace admin permissions to all principals exceptprocurement-manager-role; create a second SCP at the organization root that denies all principals the ability to create IAM roles namedprocurement-manager-role. -
D) Create an IAM role named
procurement-manager-rolein all developer AWS accounts; attach theAWSPrivateMarketplaceAdminFullAccessmanaged policy to this role; create an SCP in Organizations that denies Private Marketplace admin permissions to all principals exceptprocurement-manager-role; apply this SCP to all shared services accounts.
Correct Answer #
Option C.
Step-by-Step Winning Logic #
This solution leverages AWS Organizations Service Control Policies (SCPs) to enforce governance at the organizational boundary, which is the only mechanism that can:
- Override account-level permissions (including root user and AdministratorAccess roles)
- Prevent privilege escalation through a secondary SCP that blocks creation of the protected role name
- Centralize policy management at the root level rather than requiring 47 account-level policy deployments
Why the dual-SCP pattern is critical:
- First SCP: Implements a “Deny all except” pattern using the
aws:PrincipalArncondition key to allow onlyarn:aws:iam::*:role/procurement-manager-roleto performaws-marketplace:*actions with Private Marketplace scope - Second SCP: Prevents the attack vector where a malicious actor creates a new IAM role with the same name in an unauthorized account to bypass the first SCP
FinOps Angle:
By restricting Marketplace administration to a named role in shared services accounts (not scattered across developer accounts), you create a single approval workflow that integrates with procurement systems for budgeting and vendor negotiations—critical for achieving enterprise pricing discounts (typically 15-30% below list price).
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option A?
- Scalability nightmare: Requires maintaining inline deny policies on potentially hundreds of IAM principals across 47 accounts
- Fragile security: IAM policies are account-scoped and can be modified by account administrators, creating a privilege escalation path
- PowerUserAccess doesn’t grant Marketplace admin permissions anyway—this is a red herring
- Operational overhead: Every new user/role requires policy updates across all accounts
Why not Option B?
- Permission boundaries don’t work this way: A permissions boundary limits what a principal can do; it doesn’t grant permissions. Attaching a boundary containing
AWSPrivateMarketplaceAdminFullAccessto developer roles would still require those roles to have explicit allow statements for those actions in their identity-based policies - AdministratorAccess to procurement-manager-role is excessive and violates least-privilege
- Doesn’t prevent account admins from modifying the Private Marketplace themselves
Why not Option D?
- Architectural inversion: The role should exist in shared services accounts (where procurement managers work), not in developer accounts
- SCP misapplication: Applying the restrictive SCP to shared services accounts would block the procurement-manager-role from doing its job
- Doesn’t include role-name protection, allowing bypass through role creation
The Architect Blueprint #
graph TB
subgraph "AWS Organization Root"
SCP1[SCP 1: Deny Private Marketplace Admin
EXCEPT procurement-manager-role]
SCP2[SCP 2: Deny IAM CreateRole
IF RoleName = procurement-manager-role]
end
subgraph "Shared Services Account"
PMRole[IAM Role: procurement-manager-role
Policy: AWSPrivateMarketplaceAdminFullAccess]
PM[Procurement Manager]
end
subgraph "Developer Account 1..N"
Dev[Developers]
DevRole[Developer Roles]
end
PM -->|AssumeRole| PMRole
PMRole -->|Manage Catalog| PMP[Private Marketplace]
SCP1 -.->|Enforces| PMRole
SCP1 -.->|Blocks| Dev
SCP1 -.->|Blocks| DevRole
SCP2 -.->|Prevents Bypass| Dev
style SCP1 fill:#ff6b6b,stroke:#c92a2a,color:#fff
style SCP2 fill:#ff6b6b,stroke:#c92a2a,color:#fff
style PMRole fill:#51cf66,stroke:#2f9e44,color:#000
style PMP fill:#748ffc,stroke:#4c6ef5,color:#fff
Diagram Note: The dual-SCP pattern creates a “tamper-proof” governance layer at the organization root that both restricts Private Marketplace admin actions to a named role AND prevents creation of unauthorized roles with that name—a defense-in-depth approach to prevent privilege escalation.
The Decision Matrix #
| Option | Est. Implementation Complexity | Est. Monthly Cost Impact | Pros | Cons |
|---|---|---|---|---|
| A | Very High – Requires policy deployment to hundreds of principals across 47 accounts + ongoing maintenance for new IAM entities | Medium ($800/mo) – Labor cost: ~40 hours/month policy management at $20/hour blended rate | • Account-level granularity • No new AWS services required |
• Not enforceable against account admins • Fragile security model • Massive operational overhead • Doesn’t prevent role name reuse |
| B | Medium – Permission boundaries require careful testing; AdministratorAccess creates audit concerns | Low ($200/mo) – Initial setup effort only | • Uses native IAM constructs • Centralized boundary policy |
• Fundamentally incorrect use of permission boundaries • Grants excessive permissions • Doesn’t actually solve the problem |
| C ✅ | Low – Two SCPs at root; role creation in shared services accounts only | Negligible ($5/mo) – SCP evaluation has no cost; minimal IAM role cost | • Organization-wide enforcement • Prevents privilege escalation • Centralized governance • Tamper-proof by design • Minimal operational overhead |
• Requires understanding of SCP syntax • Must carefully test SCP conditions to avoid lockout |
| D | Medium – Role deployment across many accounts; SCP logic inverted | Medium ($400/mo) – Role sprawl creates audit complexity + potential compliance gaps | • Uses SCPs (correct tool) • Programmatic enforcement |
• Wrong account placement for roles • Inverted SCP application • No role-name protection • Blocks legitimate procurement activity |
FinOps Cost-Benefit Analysis:
Scenario: 47 accounts, average 8 Marketplace subscriptions per account, $250/month average subscription cost.
- Without Private Marketplace governance: Estimated 18% duplicate/unapproved purchases = $16,920/month waste
- Option C implementation cost: $5/month + 8 hours setup (one-time)
- Break-even: Achieved in first month
- Annual savings potential: ~$203,000 in prevented duplicate purchases + negotiated volume discounts
Real-World Practitioner Insight #
Exam Rule #
“For the SAP-C02 exam, when you see ‘prevent all principals including account administrators’, immediately think Service Control Policies (SCPs) at the organization level. IAM policies alone cannot restrict account-level admin access.”
Real World #
In production environments, we typically enhance Option C with:
- AWS CloudTrail + EventBridge integration to alert on SCP modification attempts
- Tagging strategy for the
procurement-manager-roleto enable automated compliance scanning - Cross-account role assumption from a dedicated “procurement account” rather than per-OU shared services accounts for larger organizations (100+ accounts)
- Integration with ServiceNow/Jira for Marketplace request workflows before procurement manager approval
- Cost allocation tags automatically applied to all Marketplace purchases via AWS Service Catalog + Private Marketplace integration
- Quarterly SCP reviews using AWS IAM Access Analyzer to detect unused exceptions
Common pitfall we see in the field:
Teams implement the SCP correctly but forget to document the exception process for emergency procurement. We recommend a “break-glass” procedure using AWS SSM Parameter Store to temporarily store an override token that triggers a Lambda function to modify the SCP, with automatic revert after 4 hours + executive notification.