How do you auto-remediate 0.0.0.0/0 security groups across AWS Organizations?

Why the Answer Is Correct

AWS Config is the service designed to evaluate resource configuration against a rule and mark resources as noncompliant. In this scenario, a Config rule can detect security groups with inbound 0.0.0.0/0 rules, and AWS Config remediation can invoke an SSM Automation document or Lambda function to revoke the open rule and authorize the approved intranet CIDR instead. With AWS Organizations, AWS Config can be centrally deployed through a delegated administrator and an organization aggregator so member accounts are evaluated consistently. Option A therefore covers both required parts: organization-wide detection and automatic remediation to a specific CIDR block.

Why the Other Options Are Wrong

Option B uses an IAM policy to deny creation of open security groups, but it does not detect or remediate existing groups and it depends on every user and role being covered correctly. Option C could theoretically inspect and modify security groups with Lambda, but a standalone Lambda function does not provide AWS Config compliance evaluation, organization-wide visibility, or the managed remediation workflow the question asks for. Option D uses an SCP to prevent new open security groups, but SCPs are preventive controls and cannot change the source address of an existing security group. Only Option A combines continuous compliance detection with automated remediation of existing noncompliant security groups.

Community Comment Notes

Bad_Mat's comment aligns with this verdict, stating "The correct answer is A" and describing an AWS Config rule with automatic remediation to the approved CIDR block. No commenter argued for the SCP or IAM policy alternatives. The community input is consistent with the AWS Config detection-and-remediation design required by the question.