SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Refer to the exhibit.

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

A SysOps administrator is troubleshooting a Lambda function that does not write logs to CloudWatch Logs. The IAM role attached to the function includes the policy shown. What is the most likely reason the logs are not being created?

⚠ Common exam trap

The trap here is that candidates often overlook the Resource ARN mismatch and instead focus on missing permissions or VPC connectivity, but the core issue is that the IAM policy's log group ARN does not match the actual log group name Lambda tries to use.

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 log group name in the Resource ARN does not match the actual log group created by the Lambda function.

The IAM policy shown in the question includes a Resource ARN that specifies a specific log group name (e.g., `/aws/lambda/MyFunction`). If the Lambda function is configured to write to a different log group (e.g., `/aws/lambda/MyOtherFunction` or a custom log group), the `logs:CreateLogGroup` and `logs:CreateLogStream` permissions will fail because the ARN does not match. This mismatch prevents the function from creating the log group or stream, so no logs are written to CloudWatch Logs.

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 Resource ARN does not match the actual log group created by the Lambda function.
Why this is correct
Lambda automatically creates a log group named /aws/lambda/<function-name> in the same Region as the function. If the Resource ARN in the IAM policy points to a different log group name (e.g., a typo or a custom group like /aws/lambda/my-function-v2), CloudWatch Logs rejects the write attempt even though the role and actions are correct. The resulting CloudWatch Logs error typically indicates that the specified log group does not exist or the resource ARN does not match, which matches this root cause.
✗
The IAM role is not assigned to the Lambda function's execution role.
Why it's wrong here
This answer is incorrect because the execution role is already attached to the Lambda function; otherwise the function would have no permissions to call any AWS services or even start execution. The administrator is troubleshooting an existing function whose role is properly assigned, as confirmed by checking the function configuration. The problem lies not in role assignment but in the scope of the permissions within that role, specifically the resource ARN used for the log group.
✗
The Lambda function is in a VPC without a VPC endpoint for CloudWatch Logs.
Why it's wrong here
This answer is incorrect because a Lambda function in a VPC can still publish logs to CloudWatch Logs using a NAT gateway or a VPC interface endpoint is not required. Without a VPC endpoint, the function can reach the public CloudWatch Logs service through a route to an internet gateway via the NAT device. Since the question does not mention a NAT gateway being absent and the log group name mismatch is a more specific cause, this option is not the correct explanation.
✗
The policy does not include the logs:PutLogEvents permission.
Why it's wrong here
This answer is incorrect because the IAM policy already grants the logs:PutLogEvents action, so the permission is present. The issue is that the Resource ARN in that policy statement is scoped to a log group name that does not match the one Lambda actually creates. If the action were missing, the error would be an explicit access denied for the logs:PutLogEvents action, rather than a log group name mismatch.

Quick reference

Cloud Service Model Comparison

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, apps, data	Hardware, hypervisor, networking	EC2, Azure VMs, GCP Compute Engine
PaaS	Apps and data	OS, runtime, middleware, hardware	Elastic Beanstalk, Azure App Service
SaaS	Data and settings only	Everything else	Microsoft 365, Salesforce, Workday
FaaS / Serverless	Function code only	Infra, scaling, runtime	Lambda, Azure Functions, Cloud Run
CaaS	Containers and apps	Kubernetes, OS, hardware	EKS, AKS, GKE

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Cloud Service Model Comparison

Related to this question