Study DOP-C02 event-driven configuration changes, remediation, Systems Manager automation, and state correction.
This task is where DOP-C02 asks whether the platform can correct drift or unhealthy state safely. The exam is not looking for reckless automation. It is looking for configuration changes that are triggered by reliable signals, scoped to the actual problem, and reversible if the remediation is wrong.
The current domain guidance points to:
That means the core question is often whether the system should self-correct, and if so, how narrowly.
| Requirement | Strongest first fit | Why |
|---|---|---|
| Reapply or enforce known configuration on a fleet | Systems Manager automation or state-management pattern | Strong for repeatable controlled fixes |
| Correct rule violations against a defined baseline | Config rule plus remediation flow | Matches compliance drift to corrective action |
| Replace unhealthy capacity with known-good instances | Auto Scaling or immutable replacement pattern | Safer than patching broken nodes in place |
| Apply emergency change to a narrow target set | Scoped automation with clear filters and approval where needed | Limits blast radius |
The strongest answer often turns on this question: do we trust the event enough to automate a change?
If the signal is noisy or ambiguous, the better answer may notify humans, collect more evidence, or route through an approval step. If the signal is narrow and well-understood, controlled auto-remediation becomes stronger.
If the scenario is about recurring drift, the exam usually wants a desired-state or policy-driven correction pattern rather than an operator script that patches symptoms one machine at a time.
That is why Systems Manager, Config, Auto Scaling, and immutable replacement patterns show up so often here.
When the question is about changing system state after an event, ask three things:
Those three checks usually eliminate the weakest choices.