DOP-C02 Incident and Event Response Practice Question
A company's DevOps team uses AWS Config to monitor resource compliance. They have created a custom AWS Config rule that triggers an AWS Lambda function to evaluate whether EC2 instances have the 'Environment' tag with value 'Production' or 'Staging'. The rule is set to evaluate resources on configuration changes. However, the team notices that the rule does not trigger when an EC2 instance is launched. The Lambda function's IAM role has the necessary permissions to describe EC2 instances. The CloudWatch Logs for the Lambda function show that it is not being invoked. What is the MOST likely reason?
⚠ Common exam trap
The trap is assuming the problem is IAM or trigger type when the scenario already rules those out; the real cause is the rule's resource-type scope, which is easy to overlook because it is configured separately from the trigger.
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 AWS Config rule is not configured to trigger on AWS::EC2::Instance resources.
For an AWS Config custom rule to fire on resource creation, the rule must specify the resource types it evaluates (e.g., AWS::EC2::Instance) in its scope. If the scope does not include EC2 instances, Config will not invoke the rule's Lambda function when an instance is launched, which matches the symptom that the Lambda is never invoked despite having correct permissions. The trigger type (configuration change) is already stated as correct in the scenario, so the missing piece is the resource scope.
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 Lambda function's IAM role does not have permission to write to CloudWatch Logs.
Why it's wrong here
The Lambda function's IAM role lacking CloudWatch Logs permissions would only matter once the function is executed. Since the function is not being invoked at all (the rule is not triggering evaluation for newly launched EC2 instances), no log writes are attempted. Therefore, missing log permissions cannot cause the reported failure; the root cause lies upstream in the rule's trigger and scope configuration. If the function were invoked but failed, then log permission issues could be relevant, but that is not the case here.
- ✗
The AWS Config rule is set to evaluate resources periodically, not on configuration changes.
Why it's wrong here
The prompt states the rule is configured to evaluate on configuration changes, meaning it should react to EC2 instance launches via CloudTrail or Config notifications. A periodic trigger, by contrast, runs only on a fixed schedule (e.g., every 6 hours) and would not detect a launch until the next scheduled evaluation. Because the question explicitly indicates the rule uses configuration-change triggers, this option contradicts the given scenario. Thus, this is not the cause; the real problem is that the rule's scope excludes AWS::EC2::Instance resources.
- ✓
The AWS Config rule is not configured to trigger on AWS::EC2::Instance resources.
Why this is correct
For a custom AWS Config rule to evaluate a resource on configuration changes, the rule's scope must include that resource type. If the rule is defined without AWS::EC2::Instance in its 'Resource types' scope (or if it is scoped to a specific tag/resource ID that does not match), AWS Config will not send evaluation events to the Lambda function for EC2 instances. In this scenario, the rule has the correct trigger type (change) but its scope does not cover EC2 instances, so Config never invokes the Lambda function on instance launch. This is the exact cause of the DevOps team's issue.
- ✗
The custom rule must be deployed using AWS CloudFormation to be active.
Why it's wrong here
AWS Config custom rules can be created through the AWS Management Console, AWS CLI, AWS SDK, or AWS CloudFormation; there is no requirement to use CloudFormation. Once a custom rule is created and associated with a Lambda function, the rule is active and will be evaluated based on its trigger configuration, regardless of the deployment method. CloudFormation simply automates the deployment of the rule and its associated Lambda function, but omitting it does not leave the rule inactive. Therefore, this option is incorrect; the rule's activation is not tied to CloudFormation.
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,298 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.