Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 44 discussion

The solution that meets this requirement with the LEAST operational overhead is D. Configuring an SCP to deny the ec2:AuthorizeSecurityGroupIngress action when the value of the aws:SourceIp condition key is 0.0.0.0/0, and applying the SCP to the NonProd OU. This solution would prevent the security group inbound rule from being created in the first place and will not require any additional steps or actions to be taken in order to remove the rule. This is less operationally intensive than modifying the EventBridge rule to invoke an AWS Lambda function, adding a Config rule or allowing the ec2:AuthorizeSecurityGroupIngress action with a specific IP.

I literally just created the SCP and it works. I saw some comments that "ec2:AuthorizeSecurityGroupIngress action doesn't have any conditions" - that is not correct. This is my scp : { "Sid": "Statement1", "Effect": "Deny", "Action": [ "ec2:AuthorizeSecurityGroupIngress" ], "Resource": [ "*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "0.0.0.0/0" ] } } }

Given that the aws:SourceIp condition key refers to the IP address of the principal making the request, and not the IP address specified in the security group rule, D is not appropriate for this scenario.

D. Configure an SCP to deny the ec2:AuthorizeSecurityGroupIngress action when the value of the aws:SourceIp condition key is 0.0.0.0/0. Apply the SCP to the NonProd OU.

Service Control Policy (SCP): Restrictive Policy Enforcement: An SCP (Service Control Policy) is used in AWS Organizations to enforce account-level restrictions across accounts that belong to a particular Organizational Unit (OU). By setting an SCP to deny the ec2:AuthorizeSecurityGroupIngress action when the aws:SourceIp condition is 0.0.0.0/0, you effectively prevent all users within the NonProd OU from creating any security group rule that opens inbound traffic to the entire internet. Least Operational Overhead: SCPs are centrally managed and enforced automatically, requiring no further intervention once applied. This reduces the operational overhead to nearly zero, as it does not require ongoing monitoring, function deployments, or manual rule updates.

Why Option D is Better than Option C: Explicit Deny vs. Implicit Allow: Option C allows the action unless the aws:SourceIp is 0.0.0.0/0. This creates an implicit allow policy, which means that if any condition is not met, the action is allowed. Option D uses an explicit deny, which is more secure and straightforward. An explicit deny ensures that if the condition is met (aws:SourceIp is 0.0.0.0/0), the action is blocked regardless of other permissions.

It's A. Definitely A. Don't get confused.

Voting for A

It's A, D is incorrect as it shouldn´t be source IP but destination address

Option D

SourceIP is for requester IP address, not the CIDR referenced in the SG rule.

A (Incorrect): SG is created for a briefly. This goes against the question requirement of "remove the ability to create a security group inbound rule..." B (Incorrect): Regardless of rule, SGs can be created and remain non-complaint. C (Incorrect): See D D (Incorrect): SourceIP condition key of IAM policy is the requestor's IP address. This has nothing to do with SG's inbound rule's sourceIP. This won't allow creating any SG inbound rules when the requestor is making AWS API calls from anywhere (0.0.0.0/0). Just a crap question and choices.

The goal is to prevent the creation of Amazon EC2 security group inbound rules that include 0.0.0.0/0 as the source for all accounts in the NonProd Organizational Unit (OU) with the least operational overhead. Option D is the most straightforward and effective solution to meet the requirement with the least operational overhead. By configuring a Service Control Policy (SCP) to deny the ec2:AuthorizeSecurityGroupIngress action when the aws:SourceIp condition key is 0.0.0.0/0 and applying this policy to the NonProd OU, the company can ensure that no account within this OU can create security group inbound rules that expose resources to the entire internet. This approach leverages AWS Organizations' capability to apply governance and compliance policies at scale, thereby reducing the need for individual resource monitoring or post-creation remediation.

D is going to avoid to create the rule. A is not going to prevent, is going to remediate it...

A is out because creation of the SG is allowed albeit briefly before being updated B is noise C is out because SCPs don't allow D is the correct answer

To everyone who claimed tested D, plz try create inbound rules other than 0.0.0.0/0. D will deny all AuthorizeSecurityGroupIngress operation from your IP. that's why D is "worked"

Option D is the most direct and efficient solution. By creating an SCP that explicitly denies the ec2:AuthorizeSecurityGroupIngress action when the source IP is 0.0.0.0/0, it prevents users in all accounts under the NonProd OU from creating such open security group rules. This enforcement happens at the API level, blocking the action before the rule is created, which aligns with the goal of reducing operational overhead and proactively enforcing security best practices. It is not option C because, Option C mentions configuring a Service Control Policy (SCP) to allow the ec2:AuthorizeSecurityGroupIngress action except when the source IP is 0.0.0.0/0. While the intention is correct, SCPs do not support allow-listing in this manner; they are designed to explicitly allow or deny actions across accounts in an AWS Organization.