DOP-C02 Configuration Management and IaC 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 rule is not configured with a trigger type of 'Configuration changes' or 'Periodic'

  Why this is correct

  An AWS Config rule, whether managed or custom, must be associated with at least one trigger type — `Configuration changes` or `Periodic` — to initiate evaluations. Without such a trigger, the rule never runs, leaving all resources in a `Not evaluated` state because AWS Config has no basis to invoke the rule's evaluation logic. In the AWS Management Console, the rule would show no compliance results, which exactly matches the described symptom. Adding a configuration-change trigger (for EC2 instances) or a periodic schedule (e.g., every 24 hours) is the necessary fix.

• ✗

  AWS Config does not support custom rules

  Why it's wrong here

  This is incorrect because AWS Config explicitly provides a `Custom Rule` type that lets you define your own evaluation logic in an AWS Lambda function. You create a Lambda function that accepts the evaluation parameters and returns compliance results, then associate it with an AWS Config rule as a custom rule. The service fully supports these custom rules, so claiming AWS Config lacks this capability misrepresents a core feature. Many organizations use custom rules to evaluate resource configurations that managed rules cannot cover.

• ✗

  The Lambda function does not have permission to describe EC2 instances

  Why it's wrong here

  The immediate issue is that the rule is not triggering, so the Lambda function is never invoked; therefore, its IAM permissions to `DescribeInstances` are irrelevant at this point. Even if the Lambda lacked the necessary permissions to describe EC2 instances, that would surface as an invocation or evaluation error only after the rule triggers. Because the rule has no trigger type configured, AWS Config does not call the Lambda at all, and the permission problem is not the upstream cause. You would first need to add a trigger, and then verify that the Lambda role includes `ec2:DescribeInstances` if the custom logic depends on it.

• ✗

  The EC2 instances are not in the resource types being recorded by AWS Config

  Why it's wrong here

  This distracts from the real cause: the entire evaluation never starts because the trigger is missing. If the rule were properly triggered, AWS Config would evaluate all recorded EC2 instances, assuming EC2 is included in the recording group (which it typically is by default). The recording configuration controls which resource types are tracked, but a rule without a trigger still does nothing — it won't evaluate even those resources that are recorded. So this statement cannot be the root cause of a rule that is not evaluating any resources.

Go deeper

Related to this question