Encryption keeps data safe at rest and in transit, but it does nothing the moment an attacker is already inside your account using valid-looking credentials. That’s where the Threat Detection and Incident Response domain of the AWS Certified Security - Specialty (SCS-C02) exam lives — and it’s one of the highest-value areas to master, because it’s where the exam stops asking “how do you configure this?” and starts asking “something is wrong right now; what do you do?”
This deep dive is written from a practitioner’s perspective. We’ll cover the AWS detective and response services the exam expects you to know cold — GuardDuty, Security Hub, Amazon Detective, Macie, and Inspector — how they fit together, and how to build automated incident response with EventBridge. You’ll get the mental models the exam rewards, the AWS CLI commands that make the concepts concrete, and the distinctions that separate a correct answer from a plausible-looking wrong one.
If you need the full exam picture first, start with the AWS Security Specialty Exam Guide 2026 and the domains breakdown, then come back here to go deep on detection and response.
Where This Domain Fits on SCS-C02
The SCS-C02 exam is organized into six domains. Two of them are detection-and-response heavy:
| Domain | Weight | What it covers |
|---|---|---|
| Threat Detection and Incident Response | ~14% | Designing detection, responding to incidents, automating remediation |
| Security Logging and Monitoring | ~18% | Designing/implementing monitoring, log analysis, alerting |
| Infrastructure Security | ~20% | Network and host security controls |
| Identity and Access Management | ~16% | Authn/authz, federation, permissions |
| Data Protection | ~18% | Encryption, key management (see the KMS deep dive) |
| Management and Security Governance | ~14% | Multi-account, compliance, governance |
Detection and monitoring together account for roughly a third of the exam. The reason they’re tested so heavily is that AWS’s security model assumes breaches happen — so the skill being measured is seeing the problem fast and responding without manual toil. Get fluent with the services below and you cover a large slice of the exam.
The Detection Services: Know What Each One Sees
The most common exam trap in this domain is picking the wrong service for a scenario. Each detective service has a distinct data source and job. Memorize the boundaries.
| Service | Primary job | What it analyzes |
|---|---|---|
| GuardDuty | Continuous threat detection | VPC Flow Logs, DNS logs, CloudTrail events, EKS audit logs, S3 data events |
| Security Hub | Posture management & finding aggregation | Findings from GuardDuty, Inspector, Macie + compliance standards (CIS, PCI, AWS FSBP) |
| Amazon Detective | Investigation & root-cause analysis | A behavior graph built from VPC Flow Logs, CloudTrail, GuardDuty findings |
| Amazon Macie | Sensitive data discovery | S3 objects — classifies PII, credentials, financial data |
| Amazon Inspector | Vulnerability management | EC2, ECR container images, Lambda — CVEs and network reachability |
When you read a scenario, anchor on the data source in the question:
- “Unusual API calls / crypto-mining / connection to a known-bad IP” → GuardDuty.
- “We have findings from multiple security tools and need one prioritized view / a CIS compliance score” → Security Hub.
- “We need to investigate the scope of an incident — what else did this role touch over time?” → Detective.
- “Is there PII or are there secrets sitting in this S3 bucket?” → Macie.
- “Which of our EC2 instances or container images have unpatched CVEs?” → Inspector.
That single mapping answers a surprising number of questions.
GuardDuty: The Detection Workhorse
Amazon GuardDuty is the service the exam leans on most for this domain. It’s a managed, continuous threat-detection service that ingests several log sources automatically — VPC Flow Logs, DNS query logs, and CloudTrail management/data events — without you having to enable or store those logs yourself. That last point is a frequent exam detail: GuardDuty reads these streams directly, so you don’t need VPC Flow Logs explicitly turned on for GuardDuty to use that telemetry.
What GuardDuty detects
GuardDuty produces findings categorized by threat type — for example:
UnauthorizedAccess:EC2/SSHBruteForceCryptoCurrency:EC2/BitcoinTool.B!DNSRecon:IAMUser/ResourcePermissionsExfiltration:S3/ObjectRead.Unusual
Each finding has a severity (Low, Medium, High — scored 1.0–8.9+) and rich context. Enabling it is essentially one action per account/region:
# Enable GuardDuty in the current region
aws guardduty create-detector --enable
# List findings, most severe first
aws guardduty list-findings \
--detector-id <detector-id> \
--finding-criteria '{"Criterion":{"severity":{"GreaterThanOrEqual":7}}}'Exam-critical GuardDuty facts
- Multi-account: GuardDuty integrates with AWS Organizations. You designate a delegated administrator account that sees findings from all member accounts. Expect a question where the right answer is “delegate GuardDuty administration via Organizations” rather than configuring each account manually.
- Protection plans: Beyond the core, GuardDuty offers add-ons — S3 Protection, EKS Protection, Malware Protection, RDS Protection, Lambda Protection. If a scenario mentions detecting malware on an EC2 volume after a finding, that’s GuardDuty Malware Protection.
- Suppression rules reduce noise from known-benign findings without disabling detection. Trusted IP lists and threat lists let you tune what’s flagged.
- GuardDuty is regional — you enable it per region, and findings stay in-region unless aggregated.
Security Hub: The Single Pane of Glass
If GuardDuty finds threats, AWS Security Hub is where you manage them alongside everything else. Its two jobs on the exam:
- Aggregate findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and partner tools into a normalized format — the AWS Security Finding Format (ASFF).
- Run compliance checks against standards: CIS AWS Foundations Benchmark, PCI DSS, and the AWS Foundational Security Best Practices (FSBP).
The ASFF detail matters: because every finding is normalized into one schema, you can build a single EventBridge rule that responds to findings from any source. That’s a common design-pattern answer.
# Enable Security Hub (also enables default standards)
aws securityhub enable-security-hub --enable-default-standards
# Pull the highest-severity active findings across all integrated services
aws securityhub get-findings \
--filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}],
"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}'Key exam points:
- Security Hub is the aggregator, not a detector — it doesn’t generate threat findings on its own (beyond its compliance control checks).
- Like GuardDuty, it supports cross-region aggregation and an Organizations delegated administrator for multi-account roll-up.
- When a question asks for “a prioritized, deduplicated view of security posture across many accounts and a compliance score,” the answer is Security Hub.
Amazon Detective: From Alert to Root Cause
A GuardDuty finding tells you something happened. Amazon Detective tells you the story around it. Detective automatically builds a behavior graph from VPC Flow Logs, CloudTrail, and GuardDuty findings, letting you answer investigation questions visually: Is this API call volume normal for this role? What IPs has this instance talked to over the last two weeks? What else happened around the time of the finding?
The exam distinction to lock in:
- GuardDuty = detection (“a threat exists”).
- Detective = investigation (“here’s the scope, timeline, and root cause”).
If a scenario says the security team got a GuardDuty alert and now needs to understand the blast radius or the sequence of events, the answer is Amazon Detective — not more GuardDuty configuration. Detective ingests GuardDuty findings directly, so the typical workflow is GuardDuty detects → pivot into Detective to investigate.
Amazon Macie: Finding Sensitive Data in S3
Amazon Macie is narrowly focused: it uses machine learning and pattern matching to discover and classify sensitive data in S3 — PII, PHI, credentials, financial information. It also reports on S3 bucket security posture (public access, encryption, sharing).
Exam scenarios that point to Macie:
- “Identify which S3 buckets contain personally identifiable information.”
- “Detect when sensitive data is stored in an unencrypted or publicly accessible bucket.”
- “Generate findings when credentials are discovered in object contents.”
Macie publishes findings to Security Hub and EventBridge, so it plugs into the same automated-response pipeline as everything else. Don’t confuse it with GuardDuty’s S3 Protection, which watches for anomalous access patterns to S3 — Macie inspects the content of objects; GuardDuty watches the behavior around them.
Amazon Inspector: Vulnerability Management
Amazon Inspector continuously scans EC2 instances, ECR container images, and Lambda functions for software vulnerabilities (CVEs) and unintended network exposure. The modern version is fully automated — it scans on deploy and re-scans when new CVEs are published, producing a risk-scored finding for each.
Map it cleanly:
- “Which running workloads have known CVEs / need patching?” → Inspector.
- “Scan container images in our registry before they’re deployed.” → Inspector ECR scanning.
Inspector findings also flow into Security Hub, completing the picture: GuardDuty (active threats) + Inspector (vulnerabilities) + Macie (sensitive data) all aggregate into Security Hub, and all emit to EventBridge for automation.
Automating Incident Response with EventBridge
This is the part of the domain that separates good candidates from great ones. AWS doesn’t want you manually reacting to findings — it wants automated, repeatable response. The canonical pattern, which you should be able to draw from memory, is:
GuardDuty / Security Hub / Macie / Inspector
│ (emits finding)
▼
Amazon EventBridge ── rule matches finding pattern
│
├──► SNS topic (notify the security team)
├──► Lambda function (programmatic remediation)
└──► Systems Manager (run automation runbook)EventBridge is the glue. Every detective service emits findings as events, and an EventBridge rule matches on the event pattern and routes to targets. Here’s a rule that triggers on high-severity GuardDuty findings:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{ "numeric": [">=", 7] }]
}
}# Create the rule
aws events put-rule \
--name high-severity-guardduty \
--event-pattern file://pattern.json
# Send matching findings to an SNS topic AND a Lambda remediation function
aws events put-targets --rule high-severity-guardduty \
--targets '[{"Id":"notify","Arn":"arn:aws:sns:us-east-1:111122223333:sec-alerts"},
{"Id":"remediate","Arn":"arn:aws:lambda:us-east-1:111122223333:function:isolate-instance"}]'Common remediation patterns the exam expects
| Incident | Automated response |
|---|---|
| EC2 instance compromised (crypto-mining finding) | Lambda isolates it with a quarantine security group (no inbound/outbound), snapshots the EBS volume for forensics, tags it |
| IAM credentials exposed / leaked | Attach an explicit deny-all policy or deactivate the access key; rotate via Secrets Manager |
| Public S3 bucket with sensitive data (Macie) | Lambda applies a bucket policy / enables Block Public Access |
| Unpatched CVE (Inspector) | Systems Manager Patch Manager runbook applies patches on a maintenance window |
The mental model: detect → route via EventBridge → notify and remediate. For a deeper, hands-on treatment of the auto-remediation pattern (it shows up across multiple AWS certs), see the AWS incident response and auto-remediation guide.
A Worked Incident Response Flow
Tie it together with a realistic scenario the exam might frame as a multi-step question:
- Detect — GuardDuty raises
UnauthorizedAccess:EC2/MaliciousIPCaller.Custom(High severity): an instance is talking to a known-bad IP. - Notify — An EventBridge rule matches the finding and publishes to an SNS topic; the on-call security engineer is paged.
- Contain — The same rule invokes a Lambda function that moves the instance into an isolation security group and snapshots its volume.
- Investigate — The engineer pivots into Amazon Detective to see what the instance and its IAM role did over the prior days — was data exfiltrated? Which other resources were touched?
- Eradicate & recover — Terminate the instance, rotate any exposed credentials, patch the AMI with Inspector’s guidance, redeploy from a clean image.
- Review — All findings live in Security Hub for the post-incident report and compliance evidence.
Notice how each service plays its specific role: GuardDuty detects, EventBridge routes, Lambda contains, Detective investigates, Inspector informs eradication, Security Hub records. The exam loves this division of labor.
A 7-Day Study Plan for This Domain
| Day | Focus | Hands-on goal |
|---|---|---|
| 1 | GuardDuty fundamentals | Enable a detector, generate sample findings, read severities |
| 2 | GuardDuty multi-account & protection plans | Set up a delegated admin, explore S3/EKS/Malware protection |
| 3 | Security Hub | Enable standards, review ASFF findings, read a CIS score |
| 4 | Detective & investigation | Pivot from a GuardDuty finding into a behavior graph |
| 5 | Macie & Inspector | Run a Macie sensitive-data job; review Inspector CVE findings |
| 6 | EventBridge automation | Build a finding → SNS + Lambda remediation pipeline |
| 7 | Full incident drill | Walk the detect→contain→investigate→recover flow end to end |
The thing that separates a pass from a fail here is knowing the boundaries between services and the automated-response pattern, not memorizing every finding type. Practice mapping scenarios to services until it’s reflexive.
Practice in Realistic Exam Conditions
Reading about GuardDuty and Detective is not the same as recognizing, under time pressure, that a “investigate the blast radius” scenario means Detective and not more GuardDuty tuning. SCS-C02 is a scenario-heavy exam — the questions are long, the distractors are plausible, and speed comes from having seen the patterns before.
Sailor.sh’s AWS Certified Security - Specialty (SCS-C02) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty, including the threat-detection and incident-response scenarios covered here. Working through realistic questions is the fastest way to turn service knowledge into exam-day reflexes and to find the gaps in your understanding before they cost you points.
Pair the practice with structured study using the AWS Security Specialty study plan, review the full exam topics list, and make sure the Data Protection domain is solid too — encryption questions weave through every other domain.
Frequently Asked Questions
What’s the difference between GuardDuty and Amazon Detective?
GuardDuty detects threats — it continuously analyzes logs and raises findings when it spots something malicious. Amazon Detective investigates them — it builds a behavior graph so you can understand the scope, timeline, and root cause of a finding. The typical flow is GuardDuty detects, then you pivot into Detective to investigate. On the exam, “investigate the blast radius / what else happened” points to Detective.
Does GuardDuty require me to enable VPC Flow Logs first?
No. GuardDuty reads VPC Flow Logs, DNS logs, and CloudTrail events directly from the service streams — you don’t need to enable or store those logs separately for GuardDuty to analyze them. This is a frequently tested detail.
When should I use Macie instead of GuardDuty for S3?
Use Macie to discover and classify sensitive content inside S3 objects (PII, credentials, financial data). Use GuardDuty S3 Protection to detect anomalous access behavior (unusual reads, access from suspicious IPs). Macie inspects what’s in the objects; GuardDuty watches how they’re accessed.
How do I automate incident response in AWS?
The standard pattern is: detective services (GuardDuty, Security Hub, Macie, Inspector) emit findings → an EventBridge rule matches the finding pattern → it routes to targets like SNS (notify) and Lambda or Systems Manager (remediate). Because findings are normalized in the AWS Security Finding Format, one rule can act on findings from many sources.
What does Security Hub do that GuardDuty doesn’t?
Security Hub aggregates and prioritizes findings from GuardDuty, Inspector, Macie, and partners into one normalized view, and it runs compliance checks against standards like CIS, PCI DSS, and the AWS Foundational Security Best Practices. It’s the single pane of glass and posture manager; GuardDuty is a threat detector that feeds into it.
How heavily is incident response tested on SCS-C02?
Threat Detection and Incident Response is about 14% of the exam, and Security Logging and Monitoring adds another ~18%. Together they’re roughly a third of your score, so this domain is well worth deep preparation. See the domains breakdown for the full weighting.
Conclusion
The Threat Detection and Incident Response domain rewards a clear mental model over rote memorization. Anchor on each service’s data source and job: GuardDuty detects threats from logs it reads automatically, Security Hub aggregates and scores posture, Detective investigates the scope of an incident, Macie finds sensitive data in S3, and Inspector hunts vulnerabilities — with EventBridge stitching them into automated notify-and-remediate pipelines.
Get the service boundaries reflexive and the detect→route→contain→investigate→recover flow committed to memory, and you’ll handle the long scenario questions with confidence instead of second-guessing between plausible options. The same skills that earn points on SCS-C02 are exactly what let you catch and contain a real intrusion in production — which is the whole point of the credential.