DOP-C02 Monitoring and Logging Practice Question
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
}
]
}Refer to the exhibit. The IAM policy above is attached to a Lambda function's execution role. The Lambda function is supposed to publish custom metrics to CloudWatch using PutMetricData. However, the metrics are not appearing. What is the most likely reason?
⚠ Common exam trap
Candidates often assume the issue is always a missing IAM permission (Option A) when the real problem is often a missing required parameter in the API call, especially since PutMetricData returns success even with invalid data.
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 function needs to specify a metric name and value when calling PutMetricData.
The most likely reason the metrics are not appearing is that the Lambda function is not providing the required parameters—specifically a metric name and value—when calling PutMetricData. The IAM policy correctly grants the cloudwatch:PutMetricData action, but the API call itself must include at least a MetricName and a Value (or StatisticValues) in the MetricDatum array; otherwise, CloudWatch silently drops the request without publishing any metric. This is a common coding error where the execution role permissions are sufficient but the function logic is incomplete.
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 policy does not include the 'cloudwatch:PutMetricData' action.
Why it's wrong here
The IAM policy shown in the exhibit explicitly includes the cloudwatch:PutMetricData action in its Action array, so the Lambda execution role already has permission to publish metrics. The absence of that action is not the reason no metrics are appearing; if it were absent, the API call would fail with an AccessDenied error rather than silently produce nothing. This misdiagnosis ignores that the function is authorized and points instead to a missing permission that is clearly present.
- ✗
The policy includes unnecessary actions that conflict with each other.
Why it's wrong here
IAM policies do not define interactions between actions, so there is no concept of one action 'conflicting' with another. CloudWatch actions such as PutMetricData, ListMetrics, and GetMetricData can be listed together in the same policy and are evaluated independently for each request. Unnecessary actions might broaden permissions, but they do not block or cancel other actions, so this is not the cause of the function's failure to publish metrics.
- ✓
The function needs to specify a metric name and value when calling PutMetricData.
Why this is correct
Granting cloudwatch:PutMetricData only authorizes the API call; it does not construct or complete it. The Lambda function must send a MetricDatum object that includes both a MetricName and a numeric Value (or StatisticValues/Values), along with other optional fields like Dimensions and Timestamp. If these required fields are missing or empty, the API call cannot create a metric data point, regardless of how permissive the attached IAM policy is.
- ✗
The policy uses a wildcard resource, which is not allowed for the PutMetricData action.
Why it's wrong here
The Resource element for cloudwatch:PutMetricData must be "*" because CloudWatch metrics are not ARN-backed resources and do not support resource-level permissions. This wildcard is not only allowed but is the only valid option for this action; attempting to scope access to a specific metric name or namespace is impossible. Therefore, a wildcard resource in this policy is a correct and necessary part of the authorization, not a flaw causing the problem.
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
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,339 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.