An EKS cluster with EC2 node groups uses the Kubernetes Horizontal Pod Autoscaler and the EKS cluster Autoscaler. The DevOps team must collect cluster, node, and pod metrics and capture logs in CloudWatch to establish baseline thresholds. They need email notifications via SNS if thresholds are exceeded or if the Autoscaler fails. Which combination of steps should they take? (Choose three.)

To collect metrics and logs from an EKS cluster, the CloudWatch agent is used for host-level metrics (like EC2 node CPU/memory) and Fluent Bit is used for collecting container logs and sending them to CloudWatch Logs. Both require appropriate IAM permissions. This covers the data collection requirement. Once data is in CloudWatch, alarms are needed. CloudWatch alarms can monitor specific metrics (like CPU, memory, node health) and trigger SNS notifications when thresholds are breached. This addresses the need for notifications on cluster, node, and pod health issues. To detect Autoscaler failures, monitoring its logs for errors is crucial. A CloudWatch alarm can be configured to monitor a metric filter on the Autoscaler's deployment logs, specifically looking for error patterns. When these patterns are matched, the alarm can trigger an SNS notification. The AWS Distro for OpenTelemetry is an alternative for collecting telemetry but Fluent Bit and CloudWatch agent are standard for this specific setup. A composite alarm is less direct for individual metric thresholds. Watching deployment logs for error messages is too broad; a metric filter is more precise for actionable errors.