DOP-C02 Incident and Event Response 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.

• ✗

  Set up an AWS Config rule that triggers a Lambda function to remove the SSH rule.

  Why it's wrong here

  While AWS Config can trigger a Lambda function upon detecting a non-compliant rule, it only evaluates resources at the time of the configuration change or periodic scan, not continuously blocking the SSH rule from being re-added. This approach is tempting because Lambda remediation is commonly used for one-off fixes, but it fails to prevent future re-creation of the rule, unlike a service control policy or a proactive guard. It would be correct if the requirement were only to remove existing non-compliant rules on detection, without needing ongoing prevention.

• ✗

  Use Amazon CloudWatch Events to detect the change and invoke a Lambda function.

  Why it's wrong here

  Amazon CloudWatch Events (now part of Amazon EventBridge) captures AWS API events, but this approach is inherently reactive—it only fires after the AuthorizeSecurityGroupIngress call has already modified the security group. A Lambda function invoked by the event would then have to parse the event to find the specific ingress rule and revoke it, and if multiple rules are added in quick succession, asynchronous invocations can race or miss rules. This lacks the continuous, retrying compliance enforcement that AWS Config remediation provides, and it does nothing to prevent the rule from being added again.

• ✗

  Use AWS Service Catalog to enforce security group templates.

  Why it's wrong here

  AWS Service Catalog is designed to govern the creation of new resources by forcing users to launch approved products from curated CloudFormation templates—it is not a compliance enforcement engine for existing resources. Even if you embed a 'security group template' into a Service Catalog product, it only controls how security groups are originally provisioned via the catalog; it cannot inspect or modify pre-existing security groups or block API calls that bypass Service Catalog. Therefore it cannot detect or remove an unauthorized SSH ingress rule that was added directly to an existing group.

• ✓

  Create an AWS Config rule with an automatic remediation action using AWS Systems Manager Automation.

  Why this is correct

  This is the correct approach because AWS Config rules continually evaluate resources against a desired policy, and when they detect non-compliance they can trigger an automatic remediation action—a Systems Manager Automation document—to fix the resource. In this case the rule (such as the managed RESTRICTED_SSH rule) would flag any security group with port 22 open to 0.0.0.0/0, and the associated SSM Automation document (for example, AWS-RevokeSecurityGroupIngress) would revoke the offending rule automatically. AWS Config tracks the remediation status and retries until the resource becomes compliant, providing a closed-loop, auditable remediation process without manual involvement.

Go deeper

Related to this question