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.

• ✓

  Use AWS Config rules to evaluate resource configurations against desired policies.

  Why this is correct

  AWS Config rules evaluate the recorded configuration of AWS resources against the desired policy logic you define in a rule. A rule can be AWS-managed (e.g., requiring S3 buckets to be encrypted) or custom (via Lambda), and it runs on a change-triggered or periodic schedule to identify noncompliant resources. When a resource deviates from the policy, AWS Config flags it as noncompliant and can trigger remediation actions, making it a continuous drift-detection and compliance-audit service.

• ✗

  Use AWS CodePipeline to automatically redeploy infrastructure when changes are detected.

  Why it's wrong here

  AWS CodePipeline is an end-to-end CI/CD service that sequences build, test, and deploy actions for code and infrastructure pipelines; it has no concept of a desired state that must be compared against live resources. Even if you configure a pipeline to redeploy on changes, that action simply re-applies source code or templates without first detecting whether a resource was manually altered. Thus it can mask or overwrite drift instead of notifying you of the specific noncompliant change, so it is not a valid configuration-drift management approach.

• ✗

  Use AWS Systems Manager Patch Manager to keep instances patched.

  Why it's wrong here

  AWS Systems Manager Patch Manager automates the process of installing OS and application patches on managed instances, which addresses only a narrow slice of configuration drift—software version drift. It does not evaluate or compare the configuration of infrastructure resources such as VPCs, security groups, IAM policies, or EC2 instance attributes against a baseline. For detecting and managing broad configuration drift across your AWS account, you need services that track resource state, not just patch compliance.

• ✗

  Use AWS CloudTrail to monitor API calls that modify resources.

  Why it's wrong here

  AWS CloudTrail records every API call made in your account and stores the event logs for security auditing, but it only answers 'who changed what and when,' not 'does the current configuration match the intended baseline.' To detect drift you must have a mechanism to compare the actual resource state against a desired template or policy; CloudTrail's raw events are not parsed into a compliance view and do not highlight resources that were modified outside of CloudFormation. Therefore it is an audit log, not a configuration-management or drift-detection service.

• ✓

  Use AWS CloudFormation drift detection to identify resources that have been modified outside of CloudFormation.

  Why this is correct

  AWS CloudFormation drift detection explicitly compares the live configuration of each resource in a stack with the properties defined in the stack template, and it reports per-resource drift statuses such as IN_SYNC, DRIFTED, or MODIFIED. When a resource is changed outside of CloudFormation (for example, a security group rule added manually), drift detection flags that difference so you can decide whether to update the template or revert the change. It is a direct, template-based mechanism for identifying the exact deviations that constitute configuration drift.

Go deeper

Related to this question