DOP-C02 - Incident and Event Response - Section 5.3

Implement automated configuration changes in response to events with AWS Systems Manager Automation, AWS Config remediation and AWS Lambda.

Respond to detected events automatically by invoking Systems Manager Automation runbooks through AWS Config managed remediation, returning a drifted resource to its desired state without manual intervention. Design AWS Lambda functions as custom remediation targets where pre-built runbooks do not cover the required change.

Systems Manager AutomationAWS Config remediationAWS LambdaAutomatic remediation

Practice question for this objective

Free sampleIncident and Event Responsemedium

An organisation uses AWS Config to flag unencrypted Amazon EBS volumes. Their existing automatic remediation succeeds most of the time, but occasionally the underlying Systems Manager Automation runbook fails on a volume that is still attaching, and the resource then stays non-compliant with no further attempt. The team wants the remediation to retry on transient failure without anyone re-triggering it. Which change BEST makes the existing remediation resilient to these intermittent failures?

  • AReplace the AWS Config remediation with a daily "Systems Manager State Manager" association that re-applies the encryption fix to every volume so any volume missed earlier is eventually corrected.
  • BEnable automatic remediation retries on the AWS Config rule by setting the maximum number of automatic attempts and the retry interval so Config re-invokes the runbook on the still non-compliant resource. Correct
  • CAdd an "Amazon SNS" notification to the AWS Config rule so the team is alerted on each remediation failure and an engineer can re-run the Systems Manager Automation runbook by hand.
  • DWrap the encryption logic in an "AWS Lambda" function invoked by "Amazon EventBridge" and rely on the asynchronous Lambda retry behaviour to handle the attaching-volume failures.
Configure the maximum automatic attempts and retry interval on an AWS Config remediation action so transient runbook failures are retried without manual re-triggering. AWS Config automatic remediation lets you set how many times it will attempt the action and over what interval before it stops; when a Systems Manager Automation runbook fails transiently on a resource that remains non-compliant, Config re-invokes the runbook up to the configured limit, so an intermittently failing fix self-heals without an engineer re-running it or any code being added.

Why A is wrong: Switching to a daily association would eventually re-attempt the fix, but it abandons the event-driven model and introduces up to a day of delay, which is a larger change than the targeted retry the team is asking for.

Why B is correct: AWS Config supports configuring automatic remediation with a maximum number of attempts within a time window, so a transient runbook failure is retried by Config against the resource that is still non-compliant, without manual intervention.

Why C is wrong: An SNS alert improves visibility of failures, but it relies on an engineer to re-trigger the fix, so it does not deliver the automatic retry on transient failure that the requirement specifies.

Why D is wrong: A custom Lambda with built-in retries could work, but it discards the working managed Config remediation and adds code to maintain, which is far more rework than enabling the retry settings already available on the rule.

See more DOP-C02 practice questions, answers explained.

More in this domain

Back to all Incident and Event Response objectives, or the DOP-C02 cert hub.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.