Detection-to-Remediation Orchestration

The question this module exists to answer: once GuardDuty/Inspector/Macie/Config/Security Hub generates a finding, what ACTUALLY happens next? Does anything execute automatically? This is the wiring layer connecting every detective service already covered in this study set to an actual fix — and it's one of the most consistently tested architectural patterns on the exam.

⚡ The Direct Answer To Your Question

No. No AWS detective/security service automatically executes a remediation action by default. GuardDuty, Inspector, Macie, Security Hub, and CloudTrail Insights all do exactly ONE thing on their own: they generate a finding and (in every case covered here) automatically publish that finding as an event to Amazon EventBridge. That's it. Nothing fixes itself.

To actually DO something about a finding, YOU must build the next link in the chain: an EventBridge RULE that matches the finding's event pattern, pointing at a TARGET — Lambda, SSM Automation, Step Functions, SNS, SQS, or a third-party tool. The finding doesn't know what should happen to it; the rule and its target are what decide and execute.

The one partial exception: AWS Config has a built-in "Remediation Action" feature — you associate a Config rule directly with an SSM Automation document inside Config itself, and can set it to trigger automatically the moment a resource is found non-compliant, without you manually wiring EventBridge for that specific link. But this is still opt-in per rule, not automatic by default, and under the hood it's still SSM Automation doing the actual work.

Responsive — the orchestration layer itself Remediation — the terminal fix Cuts across every detective service already covered
EventBridge
The router — every finding lands here
Lambda / SSM
The two executors that actually fix things
SNS
Notifies — never fixes anything itself
Config only
Has a built-in auto-remediation option

The Four-Stage Mental Model — Where Your "Preventive/Defensive/Remediation" Framework Fits

You already have the right instinct organizing your study around Preventive, Detective, Responsive, and Remediation. Here's how those four stages chain together mechanically, and which AWS construct lives in each one:

1. Preventive
Stops the bad action before it happens. SCPs, RCPs, IAM policies, SGs/NACLs, Network Firewall, WAF, Verified Access, S3 Block Public Access. No finding is ever generated if prevention works — there's nothing to orchestrate.
2. Detective
Notices something happened or exists. GuardDuty, Inspector, Macie, Config (rule evaluation), Security Hub, CloudTrail+Insights. Generates a finding/event and stops. Does nothing more on its own.
3. Responsive
Decides WHAT to do and ROUTES the signal. This is the orchestration layer itself: EventBridge rules, SNS topics, Security Hub Custom Actions, Step Functions state machines. This is the layer you build.
4. Remediation
The terminal action that actually FIXES the resource. Lambda functions making AWS API calls, SSM Automation documents, Config Remediation Actions. This is where the problem actually gets solved.
⚠️ The Recurring Exam Theme

Nearly every "automatically respond to/remediate X" question on the exam is testing whether you know the full chain has to be built: Finding → EventBridge rule → Target → Actual fix. A distractor answer that just says "enable GuardDuty/Inspector/Macie" without mentioning EventBridge+Lambda/SSM is almost always wrong, because enabling the detective service alone only gets you to stage 2 of 4.

Exam Domain Mapping

DomainWhere This Shows Up
Threat Detection & Incident ResponseThe centerpiece — this IS the incident response automation architecture tested throughout that domain
Security Logging & MonitoringEventBridge as the universal event bus for every logging/monitoring service already covered
Management & Security GovernanceConfig Remediation Actions, Security Hub Automation Rules for governance-at-scale
Identity & Access ManagementLeast-privilege scoping of the Lambda/SSM Automation execution roles that perform remediation

Decision Tree — Mental Model

A Finding Exists

GuardDuty/Inspector/Macie/Security Hub/CloudWatch Alarm/Config compliance change — all automatically publish to EventBridge the moment they fire. Nothing further happens without a rule.

↓
Security Goal

Decide: does this need a human notified, an automatic fix, a multi-step workflow, or just a metadata update on the finding itself?

↓
Build the EventBridge Rule

An event pattern matching the specific finding type/severity/source, pointing at one or more targets

Notify only → SNS/SQS Fix now → Lambda or SSM Automation Multi-step → Step Functions Update finding only → Security Hub Automation Rule
↓
Implementation

Lambda/SSM Automation execution roles scoped to least privilege; Config Remediation Actions configured per-rule for the one built-in auto-fix path; Security Hub Custom Actions for analyst-triggered, on-demand response.

↓
Monitoring

CloudTrail records every Lambda invocation/SSM Automation execution; Security Hub finding workflow status updates to track remediation progress; dead-letter queues catch failed EventBridge target invocations.

↓
Remediation Executes

The Lambda function or SSM Automation document makes the actual AWS API calls that fix the resource — revoke credentials, modify a security group, remove a public bucket policy, isolate an instance.

Final Summary

Must Memorize
  • No detective service auto-remediates by default — they all stop at "finding generated, published to EventBridge"
  • EventBridge is the universal router; every service covered in this study set publishes findings there automatically
  • SNS notifies; it does NOT fix anything — never the answer to "automatically remediate"
  • Config Remediation Actions are the ONE built-in auto-fix path, backed by SSM Automation, opt-in per rule
  • Security Hub Custom Actions (manual trigger) ≠ Security Hub Automation Rules (auto-updates finding metadata only, touches no AWS resource)
Must Understand
  • The four-stage chain: Preventive (stops it) → Detective (notices it) → Responsive (routes it) → Remediation (fixes it)
  • Why Lambda and SSM Automation are the two real "executors" — everything else (SNS, EventBridge, Step Functions) routes, notifies, or orchestrates, but doesn't itself call the AWS API that fixes the resource
  • Security Hub CSPM and the new unified Security Hub can BOTH have EventBridge rules defined — overlapping rules can cause duplicate actions
Can De-prioritize
  • Exact EventBridge pricing per million events
  • Full list of every pre-built SSM Automation document name
  • Console UI navigation specifics

Exam appearance probability: HIGH

Core Mechanics — Deep Dive

The Core Truth — No Service Fixes Itself Read this first
  • GuardDuty generates a finding. It does not block traffic, revoke credentials, or isolate an instance. The one exception that LOOKS automatic — Malware Protection automatically snapshotting and scanning an EBS volume after a suspicious finding — is GuardDuty investigating further, not remediating. The compromised instance is still running afterward.
  • Inspector generates a finding listing a CVE. It does not patch anything, rebuild a container image, or update a dependency version.
  • Macie generates a finding that sensitive data exists or a bucket is public. It does not change the bucket's public-access setting.
  • Config generates a compliance finding (detective mode) by default. It can ALSO auto-remediate if — and only if — you explicitly attach a Remediation Action to that rule and set it to automatic. This is the one true exception, covered in depth below.
  • Security Hub aggregates findings from the above and republishes them to EventBridge. It adds correlation and prioritization (exposure findings), but still does not touch any AWS resource on its own.
  • CloudWatch Alarms (built on metric filters from CloudTrail or other log sources) transition to ALARM state. This state transition can publish to SNS directly, or be captured as an EventBridge event — but the alarm itself does not remediate.
The pattern, restated

Every single one of these services' job ends at "I noticed something and told someone (or something) about it." The decision about WHAT to do, and the actual ACT of doing it, lives in infrastructure you build separately: EventBridge rules and their targets.

Amazon EventBridge — The Central Nervous System The universal router
What it isA serverless event bus — services PUBLISH events to it, and RULES you define match specific event patterns and route matching events to one or more TARGETS
Native publishers (no setup needed)GuardDuty, Inspector, Macie, Security Hub (both CSPM and the new unified layer), Config (compliance state changes), CloudWatch Alarms — ALL automatically publish their events to EventBridge with zero configuration on your part
What YOU must buildThe RULE — an event pattern (matching on source, detail-type, specific field values like severity or finding type) — and at least one TARGET that the rule invokes when a matching event arrives
Supported target typesLambda functions, SSM Automation documents, EC2 Run Command, Step Functions state machines, SNS topics, SQS queues, Kinesis Data Streams, API destinations (webhooks to third-party SIEM/ticketing tools), cross-account event buses
  • A SINGLE rule can have MULTIPLE targets — the classic "fan-out" pattern: one EventBridge rule matching a Critical GuardDuty finding can simultaneously invoke a Lambda function (to isolate the instance) AND publish to an SNS topic (to notify the SOC) AND start a Step Functions execution (to orchestrate a broader incident response workflow) — all from one rule, in parallel.
  • Cross-account event buses let a centralized security account receive and route findings generated in member accounts, without each member account needing its own remediation infrastructure.
SNS & SQS — Notify, Don't Fix High-trap
SNS (Simple Notification Service)Publish-subscribe messaging — delivers a notification to email, SMS, a chat webhook, or another Lambda function. Pure delivery mechanism; performs ZERO remediation action on the underlying AWS resource
SQS (Simple Queue Service)A durable message queue — used as an EventBridge target when you want findings buffered/queued for asynchronous processing (e.g., by a worker Lambda polling the queue) rather than invoked immediately
  • SNS is frequently used in PARALLEL with Lambda on the same EventBridge rule: Lambda performs the actual fix, SNS independently notifies the team that a finding occurred — these are two separate targets of the same rule, not a sequence where one depends on the other.
  • SNS can also be used IN SEQUENCE: a Lambda function performs remediation, and as its LAST step, publishes a message to SNS summarizing what action it took — this is application logic inside the Lambda, not an EventBridge fan-out.
  • "Automatically notify the security team when a Critical GuardDuty finding occurs, with no further automated action" → SNS as the SOLE target. Adding Lambda would imply automated remediation, which the requirement explicitly excludes.
AWS Lambda — The General-Purpose Executor One of two things that actually fixes anything
Role in the pipelineCustom code that makes the actual AWS API calls to remediate the finding — revoke an IAM access key, modify a security group rule, attach a deny-all policy, remove public access from an S3 bucket, isolate an EC2 instance by changing its security group
How it's invokedAs a direct target of an EventBridge rule; invoked by an SNS topic (SNS → Lambda subscription); invoked by Security Hub Custom Actions (which themselves emit an EventBridge event that a rule then routes to Lambda); as a step within a Step Functions state machine
Execution roleNeeds an IAM execution role scoped to EXACTLY the AWS API actions required for its specific remediation task — least privilege matters even more here, since this role has the power to modify production resources automatically
  • Idempotency matters: a remediation Lambda should be safe to invoke multiple times for the same finding (e.g., EventBridge occasionally delivers duplicate events) without causing errors or unintended side effects — checking current state before acting is standard practice.
  • "Automatically revoke credentials when GuardDuty detects instance credential exfiltration" → EventBridge rule matching that specific finding type → Lambda target calling iam:DeleteAccessKey or attaching a deny-all session policy.
SSM Automation & AWS Config Remediation Actions High — the standardized runbook + the one built-in auto-fix path
SSM Automation DocumentA standardized, often AWS-pre-built, reusable "runbook" defining a remediation procedure as a structured document — e.g. AWS-EnableS3BucketLogging, AWS-DisablePublicAccessForSecurityGroup — instead of writing bespoke Lambda code for every common fix
Invocation pathsDirectly as an EventBridge target; manually via start-automation-execution; as a step inside a Step Functions workflow; OR — uniquely — directly from AWS Config's own remediation configuration
Config Remediation Actions — the one built-in exceptionYou ASSOCIATE a Config rule with a specific SSM Automation document directly within Config itself. This is configured PER RULE and is opt-in — Config does not do this by default for any rule
Auto Remediation: Yes vs NoWhen set to automatic, Config triggers the associated SSM Automation document THE MOMENT a resource is evaluated non-compliant — no manual EventBridge wiring required for this specific link. When set to manual, a human must explicitly click "Remediate" in the console/API for each non-compliant resource
Rate limitingConfig remediation supports limiting concurrent executions, preventing a sudden mass-non-compliance event (e.g., a bad policy rollout) from triggering thousands of simultaneous automation executions at once
  • This is the ONE place in the entire detection layer where "auto-remediate" can be configured without you personally building the EventBridge rule — but it's still YOUR explicit configuration choice, not a default behavior, and it only applies to Config-evaluated findings, not GuardDuty/Inspector/Macie/Security Hub findings directly.
  • "A Config rule should immediately fix non-compliant S3 buckets without requiring a person to click anything" → Config Remediation Action, with Auto Remediation set to Yes, pointing at an SSM Automation document.
AWS Step Functions — Multi-Step Orchestration When one Lambda call isn't enough
What it doesOrchestrates a STATE MACHINE — a defined sequence of steps, each potentially calling Lambda, SSM Automation, or other AWS services, with built-in retry logic, error handling, parallel branches, and (critically) human-approval WAIT states
When to reach for it over a single LambdaWhen remediation genuinely requires MULTIPLE sequential or conditional steps — e.g., snapshot a compromised instance for forensics → isolate it (change security group) → notify the SOC → WAIT for human approval → only then terminate the instance
Closing the loopA common pattern: the final step of the state machine calls the Security Hub API to update the original finding's workflow status to RESOLVED, providing a clean audit trail showing the finding was actually addressed, not just acted upon silently
  • "Remediation must include a mandatory human approval step before a production EC2 instance is terminated, even after automated isolation" → Step Functions with an approval wait state, not a single direct Lambda invocation (which has no native pause-for-approval capability).
Security Hub: Custom Actions vs Automation Rules High-trap — two similarly-named, fundamentally different mechanisms
Custom ActionsA button an ANALYST manually clicks in the Security Hub console (or via API) on one or more SELECTED findings — clicking it emits a specific EventBridge event (Security Hub Findings - Custom Action), which a rule you've built then routes to a Lambda/SSM Automation target
Custom Actions = human-in-the-loop triggerThis is the pattern for "let an analyst review a finding, decide it's a true positive, and THEN manually trigger automated remediation" — analyst judgment gates the automation, but once triggered, the remediation itself can be fully automated
Automation Rules (distinct, newer capability)Rules that operate ENTIRELY WITHIN Security Hub itself — automatically updating FINDING METADATA (severity, workflow status, notes, suppression) based on ASFF field criteria, the moment a finding is created or updated
Automation Rules touch ZERO AWS resourcesThey never call an AWS API against the underlying resource — they only change how the FINDING RECORD looks/behaves in Security Hub (e.g., auto-suppress a known false-positive finding type, auto-escalate severity for findings affecting a tagged "production-critical" resource, auto-set workflow status to IN_PROGRESS for compliance findings)
  • The trap: "automatically suppress findings of a specific known-benign type" sounds like remediation but is actually an Automation Rule task — no Lambda, no EventBridge, no AWS resource touched, purely a Security Hub-internal finding-metadata operation.
  • Rule overlap warning: if EventBridge rules are defined against BOTH Security Hub CSPM's event stream AND the new unified Security Hub's event stream for overlapping finding types, this can cause DUPLICATE actions to fire — AWS explicitly recommends auditing for this overlap and disabling the redundant rule set.
  • "Let a security analyst manually decide which findings get remediated, while still automating the actual fix once approved" → Security Hub Custom Action → EventBridge rule on the Custom Action event → Lambda/SSM Automation target.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Automatically respond to a Critical GuardDuty finding by isolating the affected EC2 instance
automatically respondisolate instance
Expected Answer

EventBridge rule matching the GuardDuty finding event → Lambda target that modifies the instance's security group

DistractorWhy it's wrong
"Enable GuardDuty" aloneGuardDuty only generates the finding — it never isolates anything itself; the orchestration layer must be built
SNS notification aloneNotifies a human but doesn't AUTOMATICALLY isolate anything — fails the "automatically respond" requirement
Notify the security team of any High/Critical Security Hub finding, with no automated remediation action
notify onlyno automated action
Expected Answer

EventBridge rule → SNS topic (as the sole target)

DistractorWhy it's wrong
EventBridge rule → LambdaImplies an automated fix, which the requirement explicitly excludes
Ensure a Config rule automatically fixes non-compliant S3 buckets the instant they're detected, with no manual step
Config ruleautomatic, no manual step
Expected Answer

Config Remediation Action attached to the rule, with Auto Remediation set to Yes, backed by an SSM Automation document

DistractorWhy it's wrong
Manually build a separate EventBridge rule for the Config compliance-change eventWorks, but is MORE complex than necessary — Config's own built-in remediation configuration is the more direct, purpose-built answer for this exact scenario
Config Remediation Action with Auto Remediation set to NoStill requires a human to click "Remediate" — fails the "no manual step" requirement
Require a human approval step before an automated workflow terminates a production instance, after automatically isolating it first
multi-stephuman approval gatesequenced actions
Expected Answer

AWS Step Functions state machine with a wait-for-approval state between the isolation step and the termination step

DistractorWhy it's wrong
A single Lambda function performing both isolation and terminationHas no native pause-for-human-approval capability mid-execution — Step Functions is purpose-built for exactly this multi-step, gated workflow
Automatically suppress repeated, known-benign findings of a specific type, without touching any AWS resource
auto-suppressno resource touchedfinding metadata only
Expected Answer

Security Hub Automation Rule

DistractorWhy it's wrong
EventBridge rule → Lambda that calls the Security Hub API to suppress the findingTechnically achievable but unnecessarily complex — Automation Rules are the purpose-built, no-code mechanism for this exact finding-metadata-only operation
Security Hub Custom ActionRequires a human to manually click it each time — fails the "automatically" requirement

Per-Service Wiring — The Direct Reference Table

This is the table that directly answers "for THIS specific service, what's the wiring." Every row reflects what's already been covered in the relevant module, now framed through the orchestration lens.

GuardDuty
Auto-publishes to EventBridge?Yes — every finding, automatically
Any native auto-action?Malware Protection's auto-snapshot-and-scan is investigative, not remediation — the threat itself isn't fixed by GuardDuty
Standard wiringEventBridge rule on finding type/severity → Lambda (revoke credentials, isolate instance) and/or SNS (notify SOC)
Inspector
Auto-publishes to EventBridge?Yes — new/updated findings
Any native auto-action?None — purely detective
Standard wiringEventBridge rule on critical CVE findings → Lambda/SSM Automation (trigger Patch Manager) or a ticketing-system integration via API destination
Macie
Auto-publishes to EventBridge?Yes — both sensitive-data findings and bucket-posture findings
Any native auto-action?None — purely detective
Standard wiringEventBridge rule on a public-bucket-with-sensitive-data finding → Lambda that applies S3 Block Public Access to the specific bucket
AWS Config
Auto-publishes to EventBridge?Yes — compliance state change events
Any native auto-action?Yes — the one true exception. Remediation Actions, configured per-rule, can auto-trigger an SSM Automation document the moment a resource is non-compliant
Standard wiringEITHER the built-in Config Remediation Action (preferred, simpler) OR a manually-built EventBridge rule on the compliance-change event, depending on whether Config-native configuration suffices
Security Hub (CSPM + unified)
Auto-publishes to EventBridge?Yes — both layers, all new/updated findings, near-real-time
Any native auto-action?Automation Rules can auto-update finding METADATA only (severity, status, suppression) — never touches the underlying resource
Standard wiringEventBridge rule on imported findings → Lambda/Step Functions for full remediation, OR Custom Actions for analyst-gated, manually-triggered remediation. Watch for CSPM/unified rule overlap causing duplicate actions
CloudTrail / CloudTrail Insights / CloudWatch Alarms
Auto-publishes to EventBridge?CloudWatch Alarm state changes do; raw CloudTrail events require a metric filter + alarm first, or CloudTrail Lake/Insights events specifically routed
Any native auto-action?None — an alarm transitioning to ALARM state is itself just another signal
Standard wiringCloudTrail → CloudWatch Logs → metric filter → alarm → SNS (notify) and/or EventBridge (route to Lambda for automated response)

Costs, Limits & Quotas

Pricing Model

EventBridgePriced per million events published/matched; events from AWS services to the default bus are typically free, with charges applying to custom events and certain advanced features
SNS / SQSPriced per request/notification, generally low-cost at typical security-event volumes
LambdaPay per invocation + duration — remediation functions are typically short-lived and cheap unless invoked extremely frequently
SSM AutomationNo charge for AWS-owned automation documents; charges may apply for underlying resources the automation touches (e.g., EBS snapshots)
Step FunctionsPriced per state transition — multi-step workflows with many steps cost more than a single Lambda invocation, a real tradeoff against the added orchestration capability

Common Cost Mistakes

Cost Optimization

Limits & Quotas

EventBridge rule targetsMultiple targets per rule supported (the fan-out pattern) — exact maximum count is account/Region-specific
Config remediation concurrencyConfigurable rate limit on simultaneous SSM Automation executions triggered by a single Config rule
Lambda execution timeoutMaximum 15 minutes per invocation — workflows needing longer execution should use Step Functions to orchestrate across multiple invocations/steps instead
⚠️ Exam trap

A scenario describing EventBridge rules built against BOTH Security Hub CSPM's finding stream and the new unified Security Hub's finding stream, targeting the same remediation Lambda, is describing a documented risk of DUPLICATE remediation actions firing for the same underlying issue — not a robust, redundant design.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know
  • No detective service auto-remediates by default — the chain is Finding → EventBridge rule → Target → Fix
  • SNS notifies; it never fixes anything itself
  • Config Remediation Actions are the one built-in, opt-in auto-fix path, backed by SSM Automation
  • Security Hub Custom Actions (manual trigger) ≠ Automation Rules (auto-updates finding metadata only)
Good Practice
  • Scope every remediation Lambda/SSM Automation execution role to exactly the API actions it needs — least privilege matters more here since it acts automatically
  • Use fan-out (one EventBridge rule, multiple targets) to notify AND remediate in parallel rather than chaining unnecessarily
  • Build remediation Lambda functions to be idempotent, tolerating duplicate event delivery gracefully
  • Use Security Hub Custom Actions when human judgment should gate an otherwise-automated fix
Advanced Practice
  • Use Step Functions for genuinely multi-step, stateful, or approval-gated remediation workflows
  • Close the loop — have the remediation Lambda/state machine update the originating finding's workflow status to RESOLVED for audit-trail clarity
  • Use Security Hub Automation Rules to reduce noise (auto-suppress known-benign finding types) without building any EventBridge/Lambda infrastructure
  • Use cross-account EventBridge buses to centralize remediation orchestration in a dedicated security-tooling account

9 — Common Exam Traps

MisconceptionReality
"Enabling GuardDuty/Inspector/Macie/Security Hub means findings get fixed automatically"False — every one of these stops at "finding generated." Fixing requires you to build EventBridge → Target wiring
"SNS can be used to automatically remediate a finding"False — SNS is a notification delivery mechanism only; it cannot call AWS APIs to fix a resource on its own
"AWS Config rules always automatically fix non-compliant resources"Only true if a Remediation Action is explicitly attached AND set to automatic — neither is the default
"Security Hub Custom Actions and Automation Rules are the same feature with different names"False — Custom Actions are a manual, analyst-triggered EventBridge event source; Automation Rules auto-update finding metadata only, with no human trigger and no AWS resource touched
"GuardDuty Malware Protection automatically fixes a compromised EC2 instance"False — it automatically snapshots and scans the volume for further investigation; the compromise itself isn't remediated by this action

Lookalike Comparisons

ComparisonWhat actually differs
EventBridge vs SNSA routing/rules engine matching event patterns to potentially many targets vs a simple publish-subscribe notification delivery mechanism — EventBridge ROUTES, SNS DELIVERS
Lambda vs SSM AutomationCustom, bespoke code for any AWS API action vs standardized, often AWS-pre-built "runbook" documents — both are real executors, differing in reusability/standardization vs custom flexibility
Lambda/SSM Automation vs Step FunctionsA single action/call vs an orchestrated, stateful, multi-step sequence with retries and approval gates — reach for Step Functions only when a single call genuinely isn't enough
Security Hub Custom Action vs Automation RuleManually clicked by a human, triggers external EventBridge-routed action vs automatic, criteria-based, finding-metadata-only update with no resource action and no human trigger
Config's built-in Remediation Action vs manually-built EventBridge wiring for ConfigNative, simpler, configured directly on the rule vs more flexible but requires you to build the rule/target infrastructure yourself — both ultimately can invoke the same SSM Automation documents

Flashcards — 16 Cards

Click card to flip. Mark right or wrong to track score.

Click to reveal answer
1 / 16
Mark:   Score: 0/0

Practice Quiz — 9 Questions

SCS-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.

out of 9 correct