SAP-C02 Practice Question: Design Solutions for Organizational Complexity

A large financial services company uses AWS Organizations with over 200 accounts. The security team has implemented a Service Control Policy (SCP) that denies access to all services except a whitelist that includes Amazon S3, Amazon DynamoDB, AWS Lambda, and Amazon CloudWatch. Recently, the DevOps team reported that they cannot create new EC2 instances in their development account, even though the administrator explicitly attached an IAM policy allowing ec2:RunInstances. The SCP does not explicitly deny EC2. What is the most likely cause of this issue?

⚠ Common exam trap

It's easy for candidates to think an explicit IAM allow can override an SCP, but SCPs set the maximum permissions boundary, so any action not explicitly allowed by the SCP is implicitly denied.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The SCP denies all services not explicitly allowed, and EC2 is not on the whitelist

The SCP uses a deny-all approach with a whitelist of allowed services. Since EC2 is not on that whitelist, the SCP implicitly denies all EC2 actions, overriding any IAM policy that explicitly allows ec2:RunInstances. SCPs act as a guardrail that cannot be bypassed by account-level IAM policies.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The IAM role used by the DevOps team has a trust policy that does not allow EC2 actions
Why it's wrong here
A role trust policy governs who may assume the role, not which API actions the role can call; EC2 authorisation comes from identity policies and SCPs. It is tempting because trust policies are confused with permission policies, but the allow-list SCP's implicit denial of EC2 is the actual cause.
✗
The EC2 service has been disabled via AWS Config in that account
Why it's wrong here
AWS Config records resource configuration and evaluates compliance rules; it does not enable or disable services, so it cannot block ec2:RunInstances. It is tempting because Config can flag non-compliant resources, but that is detective, not preventive, and the whitelist SCP already explains the denial.
✗
The development account is in an organizational unit (OU) with a different SCP that denies EC2
Why it's wrong here
SCPs attached to a parent OU apply to every account beneath it, and an allow-list SCP implicitly denies EC2 because only S3, DynamoDB, Lambda and CloudWatch are permitted. It is tempting because the stem mentions one SCP, but multiple SCPs can attach at different levels and all apply.
✓
The SCP denies all services not explicitly allowed, and EC2 is not on the whitelist
Why this is correct
The SCP uses a whitelist model: its default is implicit denial of every service not named. Because EC2 is absent from the allowed list, ec2:RunInstances is blocked regardless of the attached IAM policy, since SCPs cap effective permissions.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 Practice Question: Design Solutions for Organizational Complexity

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question