DOP-C02 Monitoring and Logging Practice Question

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:PutLogEvents",
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:MyAppLogs:*"
    }
  ]
}

Refer to the exhibit. An IAM policy is attached to an EC2 instance role. The application on the instance is unable to send logs to CloudWatch Logs. The log group 'MyAppLogs' exists in the same account and region. What is the most likely reason for the failure?

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

✓

The policy is missing permissions to create log streams.

The policy only allows the logs:PutLogEvents action, but the application also needs permissions to create log streams (logs:CreateLogStream) and possibly describe them (logs:DescribeLogStreams). Since the log group exists, the first log delivery attempt requires creating a log stream, which is not allowed by the policy. Therefore, the most likely reason is that the policy is missing permissions to create log streams, making option D correct.

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 resource ARN is incorrect; it should include the log stream name.
Why it's wrong here
The resource ARN is not the cause of the failure. In IAM policies for CloudWatch Logs, you can specify a log group ARN with a trailing wildcard (e.g., arn:aws:logs:region:account-id:log-group:my-log-group:log-stream:*) to match any log stream within that group. This wildcard is valid for actions like logs:PutLogEvents, so the ARN correctly scopes permissions to all streams. The error therefore stems from a different permission or resource condition, not from an invalid ARN.
✗
The log group does not exist in the specified region.
Why it's wrong here
The scenario explicitly states that the log group already exists in the specified region, so a non-existent log group cannot explain the failure. Moreover, IAM policy evaluation is purely authorization-based; it does not check whether the resource actually exists. If the log group were missing, the logs:PutLogEvents API call would throw a ResourceNotFoundException, not an AccessDeniedException, which is a distinctly different failure signature than what the application is experiencing.
✗
The policy does not allow the logs:PutLogEvents action.
Why it's wrong here
The policy's Action element explicitly includes logs:PutLogEvents, so this action is not being denied. However, simply having PutLogEvents permission is insufficient if the target log stream does not yet exist, because CloudWatch Logs does not automatically create streams upon a PutLogEvents request. In practice, the application's SDK must first call logs:CreateLogStream, and if that call is denied, the entire logging operation fails even though PutLogEvents itself is allowed.
✓
The policy is missing permissions to create log streams.
Why this is correct
This is the correct cause. When an application writes log events to CloudWatch Logs, it must have an existing log stream; if the stream does not exist, the client (such as the AWS SDK or CloudWatch agent) first calls logs:CreateLogStream. The IAM policy grants only logs:PutLogEvents, so the implicit or explicit CreateLogStream call is denied, causing the overall write operation to fail. To resolve it, the policy must additionally allow logs:CreateLogStream, and possibly logs:DescribeLogStreams, on the same log group and stream resources.

Go deeper

DOP-C02 Monitoring and Logging Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question