A company runs a multi-tier web application on Amazon EC2 instances. The security team wants to continuously monitor the configuration of the EC2 security groups to ensure that no security group allows inbound SSH (port 22) access from the entire internet (0.0.0.0/0). If a security group is modified to allow such access, the company must be automatically notified and provided with a detailed record of the change, including the user who made the change. Which combination of AWS services should the company use to meet these requirements?
AWS Config can evaluate security group rules against a managed rule like 'restricted-ssh' (or a custom rule) and trigger an SNS notification when a resource is non-compliant. CloudTrail logs the API calls that made the change, and AWS Config can include the related CloudTrail event in its compliance history.
Why this answer
AWS Config continuously monitors the configuration of AWS resources, including security groups, and can evaluate them against managed rules such as 'restricted-ssh' (which checks that inbound SSH traffic is not allowed from 0.0.0.0/0). When a security group becomes non-compliant, AWS Config can trigger an Amazon SNS notification to alert the security team, and the detailed configuration history (including the user who made the change via CloudTrail integration) is available in the AWS Config timeline. This combination directly meets the requirements for continuous monitoring, automatic notification, and a detailed record of the change.
Exam trap
The trap here is that candidates often confuse AWS Config's continuous compliance monitoring with AWS Trusted Advisor's periodic checks or AWS CloudTrail's logging-only capability, leading them to choose options that lack real-time evaluation or detailed change attribution.
Why the other options are wrong
CloudTrail logs API calls but does not continuously evaluate security group configurations against a desired state; CloudWatch Logs requires custom log analysis and does not provide a managed rule for SSH access checks. This approach lacks automated compliance monitoring and notification without additional custom development.
AWS Systems Manager Inventory collects configuration data from EC2 instances, not from security groups. It cannot monitor security group rules, and CloudWatch Events alone cannot provide detailed records of changes including the user who made them.
When would these options actually be correct?
This combination would be correct if the requirement was to audit all API calls for security group modifications and trigger notifications based on specific API events (e.g., AuthorizeSecurityGroupIngress) using CloudWatch Events, rather than continuously evaluating the configuration state.
A company needs to continuously collect software inventory and patch compliance data from EC2 instances, and automatically remediate non-compliant instances by running a Systems Manager Automation document via CloudWatch Events.
Why candidates pick the wrong answer
Candidates may think that logging all API calls with CloudTrail and analyzing logs with CloudWatch Logs is sufficient to detect changes, but they overlook the need for continuous compliance monitoring and the simplicity of AWS Config managed rules.
Candidates may confuse Systems Manager Inventory with AWS Config, thinking it can track security group configurations, and overlook that CloudWatch Events lacks the detailed change recording and user identification capabilities of AWS Config.