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 CloudWatch agent is not configured to send logs to the correct log group.

  Why it's wrong here

  A misconfigured log group name in the agent's configuration file would cause logs to be delivered to a different log group, not to disappear entirely. Since the agent runs without authentication errors, the absence of logs in the expected group would likely indicate that the configured group name or stream prefix differs from the one being checked. However, this is a configuration mistake rather than a permission failure, and it would not prevent the logs from appearing somewhere in the same account and Region.

• ✗

  The CloudWatch agent is sending logs to a different AWS Region.

  Why it's wrong here

  The CloudWatch agent determines its destination Region from the 'region' field in its configuration or from the EC2 instance metadata; it does not arbitrarily transmit logs across Regions. If it were sending to another Region, you would still see the log streams in that other Region's CloudWatch Logs console, not a complete absence of data. Cross-Region delivery would require an explicit proxy or an agent configuration that points to a different endpoint, which is nondeterministic and unlikely in practice.

• ✗

  The log group has been encrypted with a KMS key that the agent does not have access to.

  Why it's wrong here

  CloudWatch Logs uses server-side encryption (SSE-KMS) at rest; the agent's PutLogEvents API call only needs to succeed at the data plane, and the encryption/decryption is performed by the CloudWatch Logs service on the destination. The IAM role used by the agent does not require kms:Decrypt or kms:GenerateDataKey permissions for writing logs — those are only needed for a user using the console to read or export encrypted logs. Therefore, an inaccessible KMS key would not block the agent from delivering new log events.

• ✓

  The IAM role attached to the EC2 instance does not have the 'logs:PutLogEvents' permission.

  Why this is correct

  The CloudWatch agent runs under the EC2 instance's attached IAM role, and each PutLogEvents API call requires the logs:PutLogEvents permission to be explicitly allowed in that role's policy. Without this permission, the API returns an AccessDeniedException, and the agent's own log file (typically in /var/log/aws/amazon-cloudwatch-agent/) will record the failure while the logs silently stop appearing in CloudWatch. This is the most common root cause when the agent is running and configured correctly but no new log events arrive.

Go deeper

Related to this question