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.

• ✓

  The log group name in the agent configuration does not match the policy resource.

  Why this is correct

  The IAM policy attached to the instance role explicitly restricts `logs:PutLogEvents` to the `arn:aws:logs:region:account:log-group:MyAppLogs:*` resource, but the CloudWatch agent's logs section in its configuration file (e.g., `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml`) references a different log group name. Because CloudWatch Logs evaluates the resource ARN of the target log group against the policy, a mismatch — even a typo or an environment suffix like `MyAppLogs-prod` instead of `MyAppLogs` — causes an `AccessDeniedException` before any log event is accepted. This is the most likely root cause in this scenario because the policy is intentionally scoped to `MyAppLogs` and the agent runs but sends nothing.

• ✗

  The CloudWatch agent is not running on the instance.

  Why it's wrong here

  If the `amazon-cloudwatch-agent` service were actually stopped or crashed, it would make no API calls at all, and you would not observe a policy-related failure; instead, the agent log would be silent and the `/var/log/aws/amazon-cloudwatch-agent` directory might not even exist. The administrator has already confirmed the agent is installed, and the symptom is that it fails to deliver logs, not that the process is down. Checking with `systemctl status amazon-cloudwatch-agent` would show the service active, and a stopped service cannot produce the IAM resource-mismatch error that the question implies, so this is not the correct explanation.

• ✗

  The IAM role does not have permission to describe log groups.

  Why it's wrong here

  The `logs:DescribeLogGroups` action is a read-only listing operation used primarily by the AWS Management Console and CLI for browsing log groups; it is not part of the log-ingestion data path. To send logs, the CloudWatch agent needs only `logs:CreateLogGroup` (if the group does not exist), `logs:CreateLogStream`, and `logs:PutLogEvents` — and in this scenario those permissions are already granted on the `MyAppLogs` ARN. A role without `DescribeLogGroups` can still append events to a known log group and stream; missing this permission would not stop the agent from writing logs, so it cannot be the cause of the delivery failure.

• ✗

  The instance does not have outbound internet access to reach CloudWatch Logs.

  Why it's wrong here

  While the CloudWatch agent normally needs outbound connectivity to reach `logs.<region>.amazonaws.com` on HTTPS, this scenario's failure mode is an IAM authorization issue, not a network issue. A lack of internet access would produce connection timeouts, DNS resolution failures, or `RequestError` messages in the agent's log, not an `AccessDeniedException` caused by a resource name mismatch. Moreover, if the instance is in a private subnet, it could still send logs through a VPC endpoint without any internet gateway, so the absence of outbound internet is not inherently fatal and is not the most likely explanation here.

Go deeper

Related to this question