SOA-C02 Monitoring, Logging, and Remediation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Attach an IAM role to the EC2 instance with permissions to call PutMetricData.

  Why this is correct

  Attaching an IAM instance profile role to the EC2 instance is the recommended and secure way to grant the application the necessary cloudwatch:PutMetricData permission. Without these credentials, any call to the PutMetricData API will fail with an authorization error, and embedding long-term access keys in the instance is a security anti-pattern. The IAM role, assumed via the instance metadata service, provides temporary credentials that are automatically rotated and scoped to the exact actions and resources allowed by the attached policy.

• ✗

  Create an SNS topic and subscribe the application to send metrics.

  Why it's wrong here

  SNS (Simple Notification Service) is a fully managed pub/sub messaging service intended for sending notifications (e.g., email, SMS, Lambda invocations) and decoupling event producers from consumers. It does not have any endpoint or integration that accepts metric data points and forwards them to CloudWatch; attempting to publish metric values to an SNS topic would simply trigger a notification, not store or plot them. Custom metrics must be submitted directly to CloudWatch via the PutMetricData API, not through SNS.

• ✗

  Install the CloudWatch Logs agent to send custom metrics.

  Why it's wrong here

  The CloudWatch Logs agent (or the unified agent in logs-only mode) is designed to collect, monitor, and ship log files (text/event data) to CloudWatch Logs, not to send numeric metric datapoints. While the unified agent can also collect system metrics if configured in its metrics mode, the older 'Logs agent' alone does not have the capability to invoke PutMetricData or generate metric series. For custom metrics, you need either the CloudWatch agent's metric collection feature or a direct call to the PutMetricData API.

• ✓

  Use the CloudWatch agent or AWS CLI to publish custom metrics using the put-metric-data command.

  Why this is correct

  This is a valid alternative to the IAM role approach: you can manually publish custom metrics using the AWS CLI command `aws cloudwatch put-metric-data` or configure the unified CloudWatch agent to collect and send application/system metrics. Both methods ultimately call the PutMetricData API, which requires the calling principal to have cloudwatch:PutMetricData IAM permissions. This approach is often used for one-off queries, scripts, or on-premises servers where an instance role is not available, but it still relies on valid AWS credentials.

• ✗

  Enable detailed monitoring on the EC2 instance to collect custom metrics.

  Why it's wrong here

  Enabling detailed monitoring on an EC2 instance merely changes the frequency of default AWS metrics—such as CPUUtilization, NetworkIn, and DiskReadOps—from 5-minute to 1-minute intervals; it does not expand the set of metrics that AWS publishes for you. Custom metrics are user-defined data points that your application or agent must submit via the PutMetricData API, and they are not affected by the instance's monitoring level. Therefore, detailed monitoring is irrelevant to collecting custom application metrics and would not achieve the desired outcome.

Go deeper

Related to this question