Monitoring, Logging, and Remediation practice questions

The S3 bucket policy denies write access from CloudTrail for that region.

Why wrong: Incorrect. A bucket policy denying CloudTrail writes would affect all regions, not a single region.

CloudTrail log file validation is disabled.

Why wrong: Incorrect. Log file validation is a security feature to ensure integrity; it does not cause missing logs.

The IAM role for CloudTrail does not have permissions to write logs from that region.

Why wrong: Incorrect. IAM roles for CloudTrail are not region-specific; permission issues would affect all regions.

Create a CloudWatch Logs subscription filter to stream logs directly to an AWS Lambda function.

Why wrong: Incorrect. While possible, this processes every log event, increasing cost and complexity. It does not natively aggregate errors for alarm triggering.

Use a third-party log aggregation tool that sends webhook notifications to an API Gateway endpoint to invoke the Lambda function.

Why wrong: Incorrect. This introduces external dependencies and additional operational overhead to manage the third-party tool.

Write a custom script that runs on an EC2 instance to poll CloudWatch Logs every minute and invoke the Lambda function.

Why wrong: Incorrect. This requires managing an EC2 instance and custom scripting, adding significant overhead.

Configure an S3 event notification for all object creation events and publish to an Amazon SNS topic that sends an email alert.

Why wrong: Incorrect. This would send notifications for all object creations, not only when objects become publicly accessible, generating noise.

Use an AWS Config managed rule to detect 's3-bucket-public-read-prohibited' and trigger an SNS notification via Amazon EventBridge.

Why wrong: Incorrect. AWS Config evaluates configuration changes periodically (e.g., every 10 minutes) and is not real-time; it may not notify within 15 minutes consistently.

Enable Amazon CloudTrail data events for the S3 bucket and create a CloudWatch Logs metric filter for PutObjectAcl (or PutObject with public ACL) and set an alarm.

Why wrong: Incorrect. While this could work, it requires more setup and CloudTrail data events incur additional costs and complexity.

Enable detailed CloudWatch Logs and search for 'timeout' strings.

Why wrong: Incorrect. Logs can contain timeout messages but do not provide line-level timing information.

Set a CloudWatch Metric Filter for 'Duration' and create an alarm.

Why wrong: Incorrect. Metrics provide aggregate performance but not line-specific details.

Enable AWS CloudTrail data events for the Lambda function.

Why wrong: Incorrect. CloudTrail logs API calls to Lambda but not internal code execution.

Amazon CloudWatch alarm + AWS Lambda + AWS Systems Manager Automation

Why wrong: While this combination could work, it is more complex than necessary. Systems Manager Automation is typically used for multi-step runbooks; for a simple stop action, Lambda with the EC2 stop API is sufficient and more straightforward.

Amazon CloudWatch Logs + Amazon EventBridge + AWS Step Functions

Why wrong: CPU utilization is a metric, not a log. CloudWatch Logs is for log data, not metrics. EventBridge can trigger on metric alarms, but Step Functions is an orchestration service that adds unnecessary complexity for a simple stop action.

AWS CloudTrail + Amazon EventBridge + AWS CodePipeline

Why wrong: CloudTrail logs API actions, not CPU metrics. CodePipeline is a CI/CD service. This combination is not appropriate for monitoring and stopping instances based on CPU utilization.

VolumeReadOps

Why wrong: VolumeReadOps counts completed read operations per minute, not pending operations.

VolumeIdleTime

Why wrong: VolumeIdleTime indicates when no I/O is occurring, not a queue of pending operations.

VolumeTotalReadTime

Why wrong: VolumeTotalReadTime is the total seconds spent on read operations, not a measure of waiting I/O.

Configure a CloudWatch alarm on DatabaseConnections that triggers an Amazon CloudWatch Events rule, which directly modifies the DB instance class using a CloudFormation custom resource.

Why wrong: CloudWatch Events can trigger targets but cannot directly modify RDS instance classes. A Lambda function is needed to call the RDS API. This option is overly complex and not natively supported.

Use an AWS Config rule to monitor DatabaseConnections and invoke an AWS Lambda function to scale the RDS instance when the threshold is breached.

Why wrong: AWS Config is designed for resource compliance and configuration history, not for real-time metric-based monitoring and scaling. It cannot directly evaluate CloudWatch metrics.

Use an AWS Systems Manager Automation runbook to periodically check the DatabaseConnections metric and adjust the RDS instance class if needed.

Why wrong: While Systems Manager Automation can perform actions, it requires a scheduled execution or manual trigger, making it less responsive than a CloudWatch alarm. It also adds complexity for a real-time scaling requirement.

Configure CloudFront access logs to be delivered to an Amazon S3 bucket, and use Amazon Athena to query logs for IPs with many 403 errors. Then manually add those IPs to a WAF IP set.

Why wrong: Athena is good for analysis but does not provide automatic remediation. This solution requires manual intervention, which is not acceptable for a security requirement that demands immediate blocking.

Enable AWS CloudTrail for CloudFront and create a CloudWatch metric filter for 'Forbidden' events. Use a CloudWatch alarm to notify the administrator via email, who then manually updates the WAF IP set.

Why wrong: CloudTrail logs API calls to CloudFront, not the actual HTTP requests to the distribution. It does not log 403 error responses for viewer requests. This approach will not detect the malicious traffic.

Use AWS Config to monitor CloudFront distributions and trigger an AWS Lambda function when a high number of 403 errors is detected by evaluating access logs stored in S3.

Why wrong: AWS Config is for resource configuration compliance, not for monitoring real-time request metrics. It cannot evaluate access logs stored in S3 for error rates.

Enable AWS CloudTrail logging for the ALB and create a CloudWatch metric filter for 'UnHealthyHostCount' events. Then create an alarm on that metric to notify via SNS.

Why wrong: CloudTrail logs API calls to the ALB, not the health check metrics. 'UnHealthyHostCount' is a CloudWatch metric emitted by the ALB, not a CloudTrail event. This approach would not capture the desired data.

Use an AWS Config rule to evaluate the health of the ALB target group and trigger an SNS notification when non-compliant.

Why wrong: AWS Config is not designed for real-time health monitoring. It can evaluate resource configuration but not dynamic metrics like target health. The correct way to monitor metrics is via CloudWatch alarms.

Create an Amazon EventBridge rule that triggers every minute to call the AWS CLI command describe-target-health and send a notification via Lambda if unhealthy count exceeds 2.

Why wrong: This approach introduces unnecessary complexity with a custom Lambda function and scheduled events. CloudWatch alarms natively monitor the 'UnHealthyHostCount' metric and can directly notify via SNS, making this the least overhead solution.

Configure AWS CloudTrail to deliver logs to Amazon CloudWatch Logs, create a metric filter for the 'CreateUser' API call, and set up a CloudWatch alarm that sends an Amazon SNS notification.

Why wrong: This method works, but it requires manual creation of a metric filter and alarm. It also ingests all CloudTrail logs into CloudWatch Logs, which can increase costs. A more efficient approach is to use Amazon EventBridge.

Write an AWS Lambda function that is triggered by Amazon S3 events when a new CloudTrail log is delivered to S3. The Lambda parses the log file for 'CreateUser' and if found, sends an SNS notification.

Why wrong: This approach involves custom code (Lambda) and is more complex. It also relies on periodic log delivery to S3, which may introduce delays. It is not the least overhead option.

Enable AWS Config and create a custom rule that evaluates CloudTrail trail configurations for events.

Why wrong: AWS Config is for evaluating configuration of AWS resources, not for real-time monitoring of API calls. It cannot directly detect specific API calls like 'CreateUser'.

Amazon Simple Notification Service (SNS)

Why wrong: SNS is a notification service; it cannot evaluate metrics or create alarms. It can be used as a target for CloudWatch alarms.

AWS CloudTrail

Why wrong: CloudTrail records API calls, not database connection metrics. It is not suitable for metric monitoring.

AWS Config

Why wrong: AWS Config evaluates resource configuration compliance, not performance metrics like database connections.

[error, HTTP, 500]

Why wrong: Square brackets are used for space-delimited patterns, but 'error' and 'HTTP 500' are not fields separated by spaces; this pattern would try to match fields named 'error', 'HTTP', and '500'.

"HTTP" && "500"

Why wrong: The && operator is not supported in CloudWatch Logs metric filter patterns. You can use space-separated terms, but quotes around each term will treat them as separate strings to match.

[HTTP, 500, ...]

Why wrong: This square bracket syntax would treat 'HTTP' and '500' as fields, and the ellipsis is not valid. It does not match a literal string.

AWS CloudTrail

Why wrong: CloudTrail records API activity, not metrics visualization.

Amazon QuickSight

Why wrong: QuickSight is a business intelligence service, not intended for simple metric graphs from CloudWatch.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides best practice checks, not metric visualization.

Amazon CloudWatch alarm with an Auto Scaling policy.

Why wrong: Auto Scaling is designed for EC2 instances, not for RDS DB instances. It cannot restart an RDS instance based on a CloudWatch metric.

Amazon CloudWatch alarm with an Amazon Simple Notification Service (SNS) topic that triggers an AWS Lambda function to restart the instance.

Why wrong: While this could work, it requires writing and maintaining custom Lambda code, introducing operational overhead. The question asks for minimal custom code.

Amazon RDS event subscription that triggers an AWS Lambda function.

Why wrong: Event subscriptions are for database events (like failover, maintenance) not for metric-based thresholds. They would not trigger based on the DatabaseConnections metric.

Create a CloudWatch Logs metric filter and a Lambda function that sends email via SES

Why wrong: This is overly complex. CPUUtilization is a metric, not a log, so a metric filter is not applicable. Lambda would add unnecessary overhead.

Create a CloudWatch Events rule that matches EC2 instance state changes and sends to SQS with a Lambda consumer

Why wrong: CloudWatch Events is for state changes (e.g., instance start/stop), not for metric threshold breaches. SQS and Lambda add complexity.

Configure a CloudWatch dashboard that displays CPU utilization and share it with the team

Why wrong: A dashboard only visualizes data; it does not send alerts or notifications.

Use Amazon CloudWatch Events to match S3 API calls from CloudTrail and route to an SQS queue.

Why wrong: This adds latency and complexity. CloudTrail delivers logs within ~15 minutes, not real-time. S3 event notifications are more direct and timely.

Deploy an application that periodically polls S3 for changes using ListObjects.

Why wrong: Polling is inefficient, not real-time, and introduces significant overhead compared to event-driven notifications.

Use AWS CloudTrail to deliver logs to CloudWatch Logs, then create a metric filter and trigger a Lambda function to send to SQS.

Why wrong: This is overly complex and introduces delays from CloudTrail log delivery and processing.

Create an Amazon EventBridge rule that triggers an AWS Lambda function to check the CPUUtilization metric and send an email via Amazon SES.

Why wrong: This adds unnecessary complexity. CloudWatch alarms already provide the needed evaluation and SNS integration.

Configure the EC2 instance to publish CPU logs to Amazon CloudWatch Logs, then create a metric filter to detect high CPU and trigger an SNS notification.

Why wrong: CPU utilization is already available as a CloudWatch metric, not a log. This approach is inefficient and requires custom log publishing.

Use AWS CloudTrail to monitor EC2 CPU metrics and send notifications to an Amazon SQS queue.

Why wrong: CloudTrail records API calls, not performance metrics. It cannot monitor CPU utilization.

CloudTrail, Amazon SNS, and AWS Lambda

Why wrong: Lambda would require custom code to process the CloudTrail event and send the notification, adding operational overhead.

CloudTrail, Amazon CloudWatch Logs, and a metric filter with an alarm

Why wrong: While this works, it requires creating a metric filter and alarm, which is more complex than using EventBridge.

AWS Config and Amazon SNS

Why wrong: AWS Config evaluates resource configurations and can send notifications on changes, but it is not designed for real-time API call event notification.

CloudWatch Logs Insights scheduled query with SNS action.

Why wrong: CloudWatch Logs Insights queries are for analysis, not real-time monitoring. Scheduled queries run periodically but do not provide the same low-latency alerting as metric filters and alarms.

Use a Lambda function that reads the log stream and sends an email via Amazon Simple Email Service (SES) when errors exceed 100.

Why wrong: This requires custom code and managing a Lambda trigger, which incurs more operational overhead than using CloudWatch's built-in alarm capabilities.

Install an agent on the application server that sends logs to Amazon SQS, then poll the queue with a Lambda function to trigger an email.

Why wrong: This adds several moving parts (agent, SQS, Lambda) and increases complexity compared to the native CloudWatch solution.

CloudWatch Logs metric filter

Why wrong: Extracts metrics from logs, not suitable for existing metrics with irregular patterns.

CloudWatch Metric Math with standard deviation

Why wrong: Requires manual threshold calculation and does not adapt automatically.

AWS CloudTrail Insights

Why wrong: Monitors API activity, not custom metrics.