While preparing for the AWS SAP-C02, many candidates confuse reactive remediation (detect-then-fix) with preventive controls (block-at-source). In the real world, this is fundamentally a decision about security posture maturity vs. operational friction. Let’s drill into a simulated scenario.
The Scenario #
GlobalFinance Corp operates a multi-account AWS environment with 10 member accounts organized under AWS Organizations. Accounts are segregated into two Organizational Units (OUs): Production OU and Development OU.
Currently, all accounts have:
- AWS Config enabled for compliance tracking
- Amazon EventBridge rules configured to detect when EC2 security groups allow inbound traffic from
0.0.0.0/0(anywhere on the internet) - Notifications sent to an Amazon SNS topic that the security team monitors
The security team has identified that while this setup provides visibility, it does not prevent developers in the Development OU from accidentally exposing resources to the public internet. The Chief Security Officer mandates that for all Development OU accounts, the creation of security group rules allowing 0.0.0.0/0 ingress must be blocked entirely, not just detected.
Key Requirements #
Block the creation of EC2 security group ingress rules with source 0.0.0.0/0 in all Development OU accounts, while maintaining existing detection capabilities for Production OU.
The Options #
- A) Modify the existing EventBridge rule to trigger an AWS Lambda function that automatically deletes the offending security group rule and sends a notification to the SNS topic. Deploy this updated rule to the Development OU only.
- B) Add the AWS Config managed rule
vpc-sg-open-only-to-authorized-portsto all accounts in the Development OU. - C) Create a Service Control Policy (SCP) that allows the
ec2:AuthorizeSecurityGroupIngressaction only when theaws:SourceIpcondition key does not equal0.0.0.0/0. Attach this SCP to the Development OU. - D) Create a Service Control Policy (SCP) that denies the
ec2:AuthorizeSecurityGroupIngressaction when theaws:SourceIpcondition key equals0.0.0.0/0. Attach this SCP to the Development OU.
Correct Answer #
Option D.
Step-by-Step Winning Logic #
Service Control Policies (SCPs) are the only AWS Organizations feature that can preventively block API actions before they execute. Key advantages:
- Preventive vs. Detective: SCPs operate at the IAM policy evaluation layer. If an SCP denies an action, the API call fails before the resource is created—no remediation lag.
- Correct Condition Key: The scenario requires blocking ingress rules with a source CIDR of
0.0.0.0/0. This is controlled via theaws:SourceIpcondition in the SCP policy, not the caller’s IP. - OU-Level Enforcement: Attaching the SCP to the Development OU automatically applies the policy to all member accounts without per-account configuration.
- No Runtime Cost: SCPs have no per-invocation cost (unlike Lambda) and no compliance evaluation delays (unlike AWS Config rules).
Why “Deny” instead of “Allow”?
- AWS evaluates policies using an explicit deny model. A deny in an SCP cannot be overridden by any identity-based or resource-based policy.
- Using an “allow” SCP (Option C) would require removing the default
FullAWSAccessSCP and rewriting all permissions—a massive operational burden.
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option A? (Lambda-based auto-remediation) #
- Reactive, not preventive: The rule is created first, then deleted. This creates a window of exposure (even if milliseconds) and generates CloudTrail noise.
- Cost at scale: Every violation triggers Lambda invocations + SNS messages. At 1,000 violations/month: ~$5-10/month in Lambda + SNS costs.
- Alert fatigue: Security teams receive notifications for issues that should never have been allowed in the first place.
Why not Option B? (AWS Config managed rule) #
- Detective control only: AWS Config rules evaluate compliance after resources are created. They flag non-compliance but do not block the action.
- Remediation still required: You’d need to pair this with SSM Automation or Lambda for auto-remediation, adding complexity.
- Cost overhead: Config rule evaluations cost $0.001 per evaluation. For high-churn dev accounts, this adds up.
Why not Option C? (Allow-based SCP with condition) #
- Condition key misunderstanding:
aws:SourceIprefers to the caller’s IP address (e.g., the developer’s workstation), not the security group rule’s source CIDR. - Operational nightmare: This approach would require replacing the default
FullAWSAccessSCP and explicitly allowing every other EC2 action, creating a maintenance burden.
The Architect Blueprint #
graph TD
Dev([Developer in Dev OU]) -->|Attempts API Call| SCP{SCP Evaluation Layer}
SCP -->|Source CIDR = 0.0.0.0/0?| Deny[API Call DENIED]
SCP -->|Source CIDR ≠0.0.0.0/0| EC2[ec2:AuthorizeSecurityGroupIngress Succeeds]
Deny --> CloudTrail[Logged in CloudTrail]
EC2 --> Config[AWS Config Records Compliance]
style SCP fill:#ff6b6b,stroke:#c92a2a,color:#fff
style Deny fill:#ffd93d,stroke:#f08c00
style EC2 fill:#51cf66,stroke:#2b8a3e
Diagram Note: The SCP intercepts the API call before resource creation. If the condition matches 0.0.0.0/0, the call is denied at the Organizations layer—no Lambda, no Config rule, no remediation needed.
The Decision Matrix #
| Option | Control Type | Est. Monthly Cost (1000 violations/month) | Pros | Cons |
|---|---|---|---|---|
| A (Lambda Auto-Remediation) | Reactive | ~$8-15 (Lambda invocations + SNS) | • Flexible logic • Existing EventBridge setup reused |
• Window of exposure • Alert fatigue • Runtime costs |
| B (AWS Config Rule) | Detective | ~$10-20 (Config evaluations + SSM for remediation) | • Compliance reporting • Audit trail |
• Does not prevent creation • Requires remediation workflow |
| C (Allow SCP) | Preventive | $0 | • No runtime cost | • Wrong condition key • Requires rewriting all SCPs • Unmanageable at scale |
| D (Deny SCP) ✅ | Preventive | $0 | • Blocks at API layer • No runtime cost • Centralized enforcement • Cannot be overridden |
• Requires Organizations setup • Less flexible than code-based remediation |
Real-World Practitioner Insight #
Exam Rule #
For the exam, always choose SCPs when the requirement is to prevent (not just detect) an action across multiple accounts in AWS Organizations. Keywords like “block,” “prohibit,” or “deny” signal SCP usage.
Real World #
In production environments, we typically use a layered approach:
- Preventive: SCPs block critical violations (e.g., public S3 buckets, overly permissive security groups).
- Detective: AWS Config + Security Hub track compliance drift for lower-risk policies.
- Reactive: Lambda-based auto-remediation for time-sensitive violations that don’t warrant an SCP (e.g., tagging enforcement).
Edge case: If you need to allow 0.0.0.0/0 for specific ports (e.g., HTTP/HTTPS for ALBs), you’d use a more granular SCP with multi-condition logic checking both aws:RequestedRegion and custom tag conditions—but this is beyond SAP-C02 scope.