A SysOps administrator needs to create a custom metric to track the number of active connections to an EC2 instance. Which steps should be taken? (Select TWO.)
You can publish custom metrics using the CLI.
Why this answer
Option B is correct because the AWS CLI `put-metric-data` command allows you to publish custom metrics directly to CloudWatch, which is the standard method for sending application-level or OS-level metrics that are not automatically provided by AWS. Option E is correct because the Amazon CloudWatch agent can collect custom metrics from the EC2 instance (e.g., active connection counts from netstat or a script) and publish them to CloudWatch, making it the recommended approach for in-guest metric collection.
Exam trap
The trap here is that candidates often confuse 'detailed monitoring' (which only increases frequency of existing metrics) with the ability to create new custom metrics, leading them to select Option A incorrectly.
How to eliminate wrong answers
Option A is wrong because enabling detailed monitoring on an EC2 instance only increases the frequency of standard hypervisor-level metrics (CPU, disk, network) from 5 minutes to 1 minute; it does not enable collection of custom metrics like active connections. Option C is wrong because CloudWatch cannot directly read metric data from an S3 bucket; you would need to use a Lambda function or other service to ingest the data into CloudWatch via PutMetricData. Option D is wrong because the EC2 console does not have a feature to enable custom metric collection; custom metrics must be published programmatically via the CloudWatch API, CLI, or an agent.