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" ] } } }

aws:SourceIp checks for the ip address of the requester - not the CIDR destination in the rule

The only correct answer is D. The questions states "to remove the ability to create a security group inbound rule that includes 0.0.0.0/0 as the source" A does not remove the ability, it only corrects the action. D is correct because it actually restricts the ability.

Not D. See here: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html. Condition key aws:SourceIp is missing for ec2:AuthorizeSecurityGroupIngress

You cannot use SCP to control SG rules

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html An Allow statement in an SCP can't have a Condition element at all.

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.