What's changed: Deepened DOP-C02 Chapter 5 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
5.2Auto-Remediation and Runbooks
Understand automating detect-to-remediate—SSM Automation (runbooks), Config auto-remediation, Lambda remediation, and Auto Scaling self-healing. Correct drift without human intervention.
Auto-remediating incidents lowers MTTR. Runbooks and Config auto-remediation execute predefined fixes mechanically.
5.2.1How auto-remediation works
- SSM Automation (runbooks): run predefined fix steps (e.g., make public S3 private, isolate an instance).
- Config auto-remediation: attach remediation actions to rule violations to auto-fix.
- Lambda remediation: flexible logic, invoked from EventBridge.
- Auto Scaling self-healing: auto-replace instances failing health checks.
Common on DOP-C02: standard fix steps = SSM Automation runbooks, auto-fix Config violations = Config remediation actions, flexible fixes = Lambda, replace unhealthy = Auto Scaling. Master the detect → EventBridge → remediate (SSM/Lambda) pattern.
Examples like "auto-make a public S3 private" or "detect unencrypted EBS and notify/fix" are typically implemented via Config rules + auto-remediation, or EventBridge + SSM Automation.
DOP-C02 probes designing remediation where "routine fixes are automatic, judgment calls keep a human in the loop." An SSM Automation runbook defines mainSteps in YAML/JSON, combining actions like aws:executeAwsApi, aws:invokeLambdaFunction, aws:branch (conditionals), and aws:approve (approval steps). Many AWS-managed runbooks exist (e.g., AWSConfigRemediation-*, AWS-DisablePublicAccessForS3Bucket), and you can author custom ones. Config auto-remediation associates a remediation runbook with noncompliant resources, running it automatically on detection (manual approval optional) with retry on failure. Lambda remediation suits fixes needing complex conditions or external API calls, invoked from EventBridge. Stateful multi-step recovery flows are orchestrated with Step Functions, including visualization, retries, and compensation (rollback). Crucial points are idempotency (safe to run the same fix multiple times) and guardrails—gate destructive operations behind approvals or condition checks so auto-remediation does not run amok. Always notify results via CloudWatch/SNS and record to CloudTrail and OpsItem for audit. Self-healing (Auto Scaling health-check replacement) is infrastructure-layer auto-recovery, complementary to these app/config-layer fixes.
| Nature of fix | Means | Key point |
|---|---|---|
| Standard procedure | SSM Automation runbook | AWS-managed/custom; approval steps |
| Auto-fix config violations | Config remediation action | Attach to rule; auto/manual |
| Complex/external logic | Lambda | Invoked from EventBridge; flexible |
| Multi-step recovery | Step Functions | Retries/branching/compensation, visualized |
Scenario: Security policy wants "public S3 made private immediately, but production data buckets require approval to avoid wrongful fixes." → Detect Config rule (s3-bucket-public-*) violations; auto-remediate generic buckets with an AWS-managed runbook. Route production-tagged buckets to a runbook with an aws:approve step so an operator approves before the fix. Notify results via SNS and record to CloudTrail.
FAQ: SSM Automation runbook or Lambda for remediation? For routine AWS operations covered by AWS-managed runbooks, or sequencing multiple AWS APIs with approval steps, SSM Automation is simpler and easier to audit. For custom logic, external-system integration, or fine data manipulation, use Lambda. Combining both via Step Functions is common.
Exam trap: Auto-remediation is powerful but dangerous without idempotency and guardrails. Unconditionally automating destructive fixes (terminating instances, changing policies) amplifies damage on a false positive. Protect production-impacting actions with approval steps or target tag conditions. Also, Config remediation requires being associated with a rule—creating only a rule does not auto-fix.
5.2.2Section summary
- Remediate = SSM Automation runbooks / Lambda
- Auto-fix = Config remediation / self-heal = Auto Scaling
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. When a public S3 bucket is detected, you want to auto-run the standard step of making it private. What?
Q2. You want Config rule violations auto-fixed without extra code. What?
Q3. Which is a common pattern for automating detect-to-remediate?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.