SOA-C02 Monitoring, Logging, and Remediation Practice Question
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.)
⚠ Common exam trap
A common mix-up: candidates 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.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use the AWS CLI to call put-metric-data and publish the custom metric.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable detailed monitoring on the EC2 instance.
Why it's wrong here
Detailed monitoring only changes the frequency of the default EC2 metrics that AWS emits, from 5-minute intervals to 1-minute intervals. It cannot emit a brand-new custom metric, and it gives you no control over the values being reported, namespace, or dimensions. To create a custom metric, you must explicitly call PutMetricData through the AWS CLI, SDK, or CloudWatch agent.
- ✓
Use the AWS CLI to call put-metric-data and publish the custom metric.
Why this is correct
Using the AWS CLI's put-metric-data command is a direct way to publish a custom metric by sending the metric name, namespace, value, unit, timestamp, and optional dimensions to CloudWatch's PutMetricData API. This works well for on-demand or scripted collection, such as a cron job that measures an application-specific value and pushes the result. The CLI call requires the cloudwatch:PutMetricData IAM permission and can optionally set StorageResolution to 1 for high-resolution metrics.
- ✗
Store the metric data in an S3 bucket and configure CloudWatch to read from it.
Why it's wrong here
CloudWatch has no mechanism to read custom metric data files from S3; S3 is an object storage service, not a metric source, and simply placing data there will not cause any metric to appear. While you could architect a solution where an S3 PUT event triggers a Lambda function that parses the object and calls PutMetricData, that would still be the CLI/SDK publishing the metric. Without such an intermediary, S3 storage alone does not satisfy the requirement to create a custom metric.
- ✗
Use the EC2 console to enable custom metric collection.
Why it's wrong here
The EC2 console does not provide any toggle or setting to enable custom metric collection; it only allows you to enable detailed monitoring for standard EC2 metrics or manage CloudWatch alarms and dashboards. Custom metrics must be generated client-side by software on the instance or by a separate process that calls the PutMetricData API. There is no console checkbox that can make CloudWatch create a metric you defined yourself.
- ✓
Install and configure the Amazon CloudWatch agent on the EC2 instance.
Why this is correct
Installing the Amazon CloudWatch agent on the EC2 instance is a valid, recommended way to collect and publish custom metrics, especially for operating-system-level metrics like memory usage, swap utilization, disk space, and custom application counters. The agent runs as a service and uses a configuration file to define metrics, then sends them to CloudWatch through the PutMetricData API. It is the most practical choice when you need continuous, recurring collection across many instances rather than one-off publishes.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.