AWS SOA-C02 Drill: Automated Security Group Compliance - Detect & Remediate 0.0.0.0/0 Exposure

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).

For SOA-C02 candidates, the confusion often lies in how to enforce security guardrails across multiple AWS accounts automatically, while balancing detection with remediation. In production, this is about knowing exactly which AWS services provide scalable compliance enforcement without overreaching with IAM or SCPs that can break workflows. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

A global fintech firm, FinSecure Systems, manages multiple AWS accounts under a single AWS Organizations umbrella. Their security team has noticed some accounts have security groups that permit inbound traffic from the unrestricted source 0.0.0.0/0, which violates corporate network policies that restrict inbound access to their private CIDR blocks only. To prevent potential security risks, the SRE team wants to implement an automated, organization-wide monitoring and remediation process that:

• Detects any security group with inbound rules allowing 0.0.0.0/0 as a source address.
• Automatically modifies noncompliant security groups to restrict access to approved internal CIDR ranges aligned with the corporate network.
• Operates at scale across all accounts managed by AWS Organizations.

The Requirement:

#

Which approach should the SysOps administrator take to build this automated detection and remediation solution?

The Options

#

• A) Create an AWS Config rule across organization accounts that flags security groups permitting inbound 0.0.0.0/0 traffic. Configure automatic remediation actions that update the security group source address to the approved CIDR blocks.
• B) Develop and attach an IAM policy to every user denying the ability to create security group rules with 0.0.0.0/0 as a source address.
• C) Build a custom AWS Lambda function that scans both new and existing security groups, detects noncompliance with 0.0.0.0/0 sources, and remediates by changing them to approved CIDR ranges.
• D) Apply a Service Control Policy (SCP) at the Organization Unit (OU) level that denies creation of security groups with 0.0.0.0/0 sources and configure automatic remediation to replace such rules with approved CIDRs.

Google adsense

#

leave a comment:

Correct Answer

#

A.

Quick Insight: The SOA-C02 Imperative

#

The key to scalable compliance and remediation in a multi-account AWS Organization is leveraging AWS Config’s integrated detection and managed remediation capabilities. Config Rules can be deployed organization-wide, provide near real-time detection, and invoke remediation Lambda functions without manual overhead or overly restrictive IAM/SCPs that risk disrupting developer workflows.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A

The Winning Logic

#

AWS Config supports organization-wide rules, enabling the security team to centrally audit security group compliance across all accounts without having to deploy complex custom code in every account. The use of AWS Config managed or custom rules allows continuous evaluation of security groups for compliance with your policy that blocks 0.0.0.0/0 ingress sources. AWS Config also supports automatic remediation actions, where it can invoke a Lambda function or Systems Manager Automation document to update security group rules to the approved CIDR blocks, thus closing the loop with proactive remediation. This approach scales with your AWS Organization and aligns with best practices for centralized compliance and automated recovery, while minimizing manual overhead.

The Trap (Distractor Analysis):

#

• Option B: IAM policies cannot easily block security group rule sources at creation granular level and would require attaching policies to every user, causing operational overhead. Additionally, this is reactive blocking rather than detection + remediation, and does not handle existing noncompliant groups.
• Option C: While Lambda can scan and remediate groups, this requires building and maintaining your own scanning framework, scheduling, cross-account permissions, and lacks native integration into AWS Organizations compliance pipelines. Reinventing Config’s capabilities leads to complexity and risk.
• Option D: SCPs serve as coarse-grained permission boundaries and do not support conditional logic to deny based on specific ingress CIDR ranges. Also, SCPs do not provide automated remediation capabilities. Using SCPs may block legitimate business traffic and halt changes improperly.

The Technical Blueprint

#

# Example: Deploy an AWS Config Custom Rule that flags security groups with 0.0.0.0/0 ingress

aws configservice put-organization-config-rule \
  --organization-config-rule-name "restricted-sg-ingress" \
  --organization-config-rule-trigger-types "ConfigurationItemChangeNotification" \
  --organization-managed-rule-name "RESTRICTED_SG_INGRESS" \
  --excluded-accounts ["123456789012"] \
  --input-parameters '{ "cidrBlock": "0.0.0.0/0", "approvedCidrs": "10.0.0.0/8,192.168.0.0/16" }' \
  --auto-remediation-enabled

Note: RESTRICTED_SG_INGRESS is a conceptual example; in practice, a custom rule Lambda with remediation may be required.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the SOA-C02 exam, always pick AWS Config when you see automated compliance and remediation across multiple AWS accounts.”

Real World

#

“In real environments, SOPs often combine AWS Config with AWS Security Hub findings and Systems Manager Automation documents for remediation, but Config remains the foundational compliance service for rule evaluation.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the SOA-C02 exam.