DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use AWS Config with a managed rule to detect and auto-remediate.

  Why this is correct

  Correct. AWS Config with the 'restricted-ssh' managed rule can detect non-compliant security groups and trigger auto-remediation, such as removing overly permissive rules or replacing them with restricted ones. This is the most scalable and integrated approach.

• ✗

  Apply a service control policy (SCP) to deny opening port 22.

  Why it's wrong here

  SCPs are an AWS Organizations feature that governs which AWS API calls principals in an account or OU can make; they cannot directly modify or rewrite security group rules, and they cannot 'deny opening port 22' as a network-level action. Although an SCP could deny the ec2:AuthorizeSecurityGroupIngress actions, that would block all ingress rule changes across the account rather than selectively restrict SSH from known IPs, and it still would not remediate rules that already exist. Network access control is enforced in the VPC by security group rules, which are evaluated in the data plane, not by IAM authorization policies.

• ✗

  Manually update each security group to restrict SSH to known IPs.

  Why it's wrong here

  Manually updating each security group is operationally brittle because it relies on human effort to track and edit every current and future group, and it fails to detect configuration drift or newly created groups that reintroduce the same SSH exposure. In a dynamic environment with many instances, this approach is time-intensive, prone to errors (e.g., allowing the wrong CIDR), and provides no audit trail or automated verification. AWS Config's managed rule, by contrast, continuously evaluates all security groups against the restricted-ssh rule and can trigger automatic remediation the moment an offending rule appears.

• ✗

  Use CloudWatch Events to trigger a Lambda function that modifies security groups.

  Why it's wrong here

  CloudWatch Events can trigger a Lambda function to modify security groups, but this approach lacks the ability to automatically detect newly created or modified EC2 instances whose security groups violate the policy. The scenario requires continuous, scalable remediation across all current and future resources, which CloudWatch Events cannot achieve without custom logic to poll for changes. This option is tempting because CloudWatch Events is commonly used to react to state changes, such as triggering a Lambda on an EC2 instance state change, and would be correct if the requirement were to remediate only existing, static security groups after a one-time audit.

Go deeper

Related to this question