Threat Detection Guardduty Securityhub

What Threat Detection Means on AWS

Threat detection on AWS is the discipline of turning raw telemetry — CloudTrail events, VPC Flow Logs, DNS queries, S3 data events, EKS audit logs, runtime syscalls, IAM access patterns, and resource configuration deltas — into prioritized, actionable findings. The SCS-C02 task statement 1.2 asks you to evaluate findings from managed AWS services, correlate them across data sources, and validate them with queries before you trigger incident response. Threat detection is therefore neither a single service nor a single dashboard; it is an opinionated pipeline that begins with GuardDuty for behavioral and threat intelligence detection, layers in Security Hub for finding aggregation and standards-based posture scoring, adds Macie for sensitive data risk, includes AWS Config for configuration drift, and uses IAM Access Analyzer for permission exposure detection.

The exam tests whether you understand the strengths, gaps, and overlaps of each service. It also tests whether you can recognize when a finding alone is not enough — when you must pivot to Detective for a behavior graph, run an Athena query against Security Lake or raw CloudTrail, or build a CloudWatch metric filter to capture an anomaly that no managed service surfaces. Modern AWS threat detection is multi-source by design; a single GuardDuty finding rarely tells the full story of an incident. This topic walks through every detection service in scope, shows how findings flow into Security Hub, and gives you decision frameworks to choose the right tool when the exam scenario calls for threat detection.

Why Threat Detection Matters for SCS-C02

Domain 1 — Threat Detection and Incident Response — carries 14 percent of the exam, and task statement 1.2 alone covers the evaluation of findings, cross-service correlation, query-based validation, and metric-based anomaly detection. In practice, that means roughly 7–9 questions on your exam will hinge on choosing between GuardDuty, Security Hub, Macie, Detective, Athena, CloudWatch, and Config. Worse, many incident response questions in tasks 1.1 and 1.3 begin with "GuardDuty raises a finding..." — meaning your understanding of threat detection determines whether you can even parse the question stem.

The exam style is rarely "what is GuardDuty?" Instead it is "GuardDuty raises an UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding on a production EC2 instance role; the security team needs to confirm whether the credential was used outside AWS and which APIs were called. Which combination of services validates this with the least operational overhead?" The right answer is rarely a single service. Threat detection mastery means you can chain GuardDuty (alert) → Detective (correlation) → Athena (validation) → Security Hub (centralization) → EventBridge (response) without hesitation.

Amazon GuardDuty Deep Dive

Amazon GuardDuty is the always-on managed threat detection service. It analyzes three foundational data sources — CloudTrail management events, VPC Flow Logs, and DNS query logs — without you enabling them explicitly, plus optional protection plans that cover specific workloads. GuardDuty uses a combination of machine learning, anomaly detection, and curated threat intelligence lists from AWS Security and partners (CrowdStrike, Proofpoint) to surface findings with severity scores from 0.1 to 8.9 and severity levels of Low (1.0–3.9), Medium (4.0–6.9), and High (7.0–8.9).

GuardDuty Protection Plans

Protection plans extend coverage beyond the foundational sources. Each plan can be enabled per account or centrally via delegated administrator at the Organizations level:

• S3 Protection — analyzes S3 data plane events (GetObject, PutObject) for credential misuse, data exfiltration patterns, and access from anonymous principals. Required for Discovery:S3/* and Exfiltration:S3/* findings.
• EKS Protection — splits into EKS Audit Log Monitoring (control plane) and EKS Runtime Monitoring (data plane via the GuardDuty agent on worker nodes). Detects pod escapes, privileged container creation, and reverse shells.
• Malware Protection — agentless scan of EBS volumes attached to suspicious EC2 instances or ECS/Fargate tasks. Triggered automatically when GuardDuty raises certain findings, or on-demand for S3 objects (Malware Protection for S3).
• RDS Protection — analyzes RDS login activity (currently Aurora MySQL/PostgreSQL) for brute-force, unusual logins, and credential compromise.
• Lambda Protection — monitors Lambda network activity for connections to known malicious IPs or coin-mining domains.
• Runtime Monitoring — extends EKS runtime detection to ECS on Fargate and EC2, using a managed agent that observes process, file, and network syscalls.

GuardDuty Finding Types

GuardDuty finding types follow the format ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.ThreatFamilyVariant!Artifact. The threat purpose is what you scan for in exam stems:

• Backdoor — instance acting as bot, C2 communication.
• Behavior — anomalous network or API behavior compared to baseline.
• CryptoCurrency — Bitcoin/Monero mining domain or pool contact.
• Discovery — reconnaissance, GetCallerIdentity from unusual location.
• Exfiltration — data being moved off-account, anomalous S3 GetObject volume.
• Impact — destructive actions, mass deletion APIs.
• Pentest — Kali, ParrotLinux, Pentoo user-agents.
• Persistence — new IAM user/role from unusual location.
• Policy — root credential usage, S3 Block Public Access disabled.
• PrivilegeEscalation — anomalous AssumeRole into highly privileged role.
• Recon — port-scanning, EC2 metadata enumeration.
• Stealth — CloudTrail logging stopped, password policy weakened.
• Trojan — DGA domains, blackhole traffic, drop-point IPs.
• UnauthorizedAccess — credential exfiltration, console login from unusual location, RDP brute-force.

Suppression Rules vs. Trusted/Threat Lists

These three controls look similar but solve different problems and the exam loves to mix them up:

• Suppression rules — auto-archive findings that match attribute filters (e.g., accountId == 111122223333 AND type == 'Recon:EC2/Portscan'). Findings are still generated but moved to archived state; they do not flow to Security Hub or EventBridge.
• Trusted IP lists — IP CIDRs that GuardDuty will not flag for VPC Flow Logs or CloudTrail-based findings. Up to one list per region, max 2,000 entries. Skips detection entirely.
• Threat IP lists — custom IP CIDRs that GuardDuty will flag with UnauthorizedAccess:EC2/MaliciousIPCaller.Custom or similar custom findings. Up to six lists per region.

AWS Security Hub Deep Dive

AWS Security Hub is the cloud security posture management (CSPM) and finding aggregation service. It performs three jobs that often blur on the exam: it aggregates findings from native AWS services and partners, it runs security standards that continuously evaluate your accounts against compliance frameworks, and it automates finding workflow with custom actions and automation rules.

Security Standards

Security Hub ships with several managed standards. Each standard is a curated set of AWS Config rules and Security Hub-native checks:

• AWS Foundational Security Best Practices (FSBP) v1.0.0 — AWS's own opinionated baseline. ~250+ controls across 30+ services. Always enable this first.
• CIS AWS Foundations Benchmark v1.4.0 / v3.0.0 — Center for Internet Security baseline; covers IAM, logging, monitoring, networking.
• CIS AWS Foundations Benchmark v1.2.0 — older legacy version, still required for some auditors.
• PCI DSS v3.2.1 / v4.0.1 — payment card industry controls.
• NIST SP 800-53 Rev. 5 — comprehensive US federal baseline; ~700+ controls.
• AWS Resource Tagging Standard — newer, focused on tagging compliance.
• Service-Managed Standard: AWS Control Tower — auto-enabled when Control Tower deploys controls.

Each control yields a PASSED, FAILED, WARNING, or NOT_AVAILABLE result. Aggregated, they produce a per-standard score and a Security Hub overall score, both of which are excellent KPIs for posture dashboards.

Finding Aggregation and Cross-Region Aggregator

Security Hub is a regional service. To centralize across regions, you configure a finding aggregator (also called cross-region aggregation) in your designated home region. The aggregator pulls findings from linked regions, and Security Hub continuously replicates updates back so that workflow status changes propagate. Combine this with the delegated administrator pattern in AWS Organizations and you get a single account, single region pane of glass for the entire org.

Custom Insights

A custom insight is a saved query against the finding store, grouped by an attribute (e.g., ResourceId, AwsAccountId, ProductArn). Insights are how you build "top 10 noisiest accounts" or "all critical findings on production resources" dashboards inside the Security Hub console. They are read-only views; they do not modify findings.

Automation Rules

Automation rules (launched 2023) let you mutate findings as they arrive, without writing Lambda. A rule has criteria (filter conditions on ASFF fields) and actions (set Workflow status, set Severity, add Note, set custom fields). Common patterns:

• Auto-suppress FSBP control failures on sandbox accounts.
• Bump severity of any finding on a tagged production: true resource.
• Add note "Reviewed by SOC tier-1" when finding matches known false-positive shape.
• Auto-resolve findings older than 90 days that match low-severity informational types.

Hub Integrations

Security Hub natively ingests findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, AWS Config (via Config Conformance Pack mapping), Firewall Manager, Health, Systems Manager Patch Manager, and IoT Device Defender. Plus 70+ partner products (CrowdStrike, Trend Micro, Palo Alto Cortex, Wiz, Lacework, etc.) all publishing in ASFF. The exam pattern: when you see "third-party scanner findings need to appear alongside AWS findings," answer Security Hub via ASFF.

Amazon Macie for Data Threat Detection

Amazon Macie discovers and classifies sensitive data in S3 buckets, then raises policy findings (bucket-level posture) and sensitive data findings (object-level content). It is the exam's go-to for "how do we detect S3 buckets containing PII / credit cards / health data?"

Managed and Custom Data Identifiers

A managed data identifier is an AWS-curated detection pattern. There are 100+ managed identifiers covering credentials (AWS access keys, GitHub tokens), financial (credit card numbers, SWIFT codes), PII (US SSN, EU passport, Brazilian CPF), and health (US HCPCS codes). You can also write a custom data identifier as a regex with proximity-based keyword requirements and a maximum match count.

Automated Sensitive Data Discovery vs Classification Jobs

Macie runs in two modes simultaneously:

• Automated sensitive data discovery — a continuously-running, sampled scan across all S3 buckets in the account/organization. Produces a sensitivity score (0–100) per bucket and per object. Always-on, low cost.
• Classification jobs — explicit, scheduled or one-time jobs that scan a defined bucket set fully (or sampled). Produces detailed sensitive data findings. Higher cost, deeper coverage.

Macie Finding Types

• Policy:IAMUser/S3BlockPublicAccessDisabled — bucket no longer enforces BPA.
• Policy:IAMUser/S3BucketEncryptionDisabled — default encryption removed.
• Policy:IAMUser/S3BucketPublic — bucket policy or ACL grants public read.
• SensitiveData:S3Object/Credentials — AWS keys / private SSH keys in object.
• SensitiveData:S3Object/Financial — credit card or financial data.
• SensitiveData:S3Object/Personal — PII matched.
• SensitiveData:S3Object/Multiple — multiple categories matched.

All Macie findings auto-publish to Security Hub when integration is enabled.

IAM Access Analyzer Deep Dive

IAM Access Analyzer is the threat detection service for permission exposure. It does not detect runtime threats; it detects policy-level risk before exploitation. The service has evolved into three distinct analyzer types that frequently confuse exam takers.

External Access Analyzer

The original analyzer. Identifies resources in your account or organization that grant access to external principals — accounts outside your zone of trust. Supported resources include S3 buckets, IAM roles (trust policies), KMS keys, Lambda functions, SQS queues, Secrets Manager secrets, RDS snapshots, EFS file systems, ECR repositories, and SNS topics. Findings show the principal, resource, condition, and access path. Best run at the organization scope so cross-account-but-still-internal access is not flagged.

Unused Access Analyzer

Launched 2023, charged separately. Identifies unused IAM users, roles, access keys, and permissions within a zone of trust (account or org). Surfaces:

• IAM users with passwords/keys not used in N days.
• IAM roles not assumed in N days.
• IAM permissions (services and actions) granted but never invoked.

Use this for least-privilege right-sizing. Findings flow to Security Hub with type Software and Configuration Checks/AWS Security Best Practices/Unused IAM Permission.

Custom Policy Checks (Validation and Custom Checks)

Two flavors:

• Policy validation — free; runs on a JSON policy document and returns findings (errors, security warnings, suggestions, general warnings) before you save the policy. Uses Zelkova-based automated reasoning.
• Custom policy checks — paid; CI/CD-friendly checks like CheckAccessNotGranted (verify a policy does not grant a specified action) or CheckNoNewAccess (verify a new policy does not grant more than the old one). Used as a guardrail in pipelines.

AWS Config as a Detection Source

AWS Config is primarily a configuration tracking service, but its rules (managed and custom) generate compliance findings that feed Security Hub. Each Config rule evaluates resource configuration against a desired state and emits COMPLIANT / NON_COMPLIANT evaluations. NON_COMPLIANT evaluations become Security Hub findings of type Software and Configuration Checks/AWS Config/Compliance.

Config detects threat-adjacent issues that GuardDuty cannot:

• S3 bucket created without default encryption (s3-bucket-server-side-encryption-enabled).
• Security group permitting 0.0.0.0/0 on port 22 (restricted-ssh).
• IAM password policy weakened (iam-password-policy).
• CloudTrail trail disabled (cloudtrail-enabled).
• Root account access keys present (iam-root-access-key-check).

Pair Config with Conformance Packs (templated bundles aligned to NIST, HIPAA, PCI) for instant compliance baselines, and with Auto Remediation (SSM Automation documents triggered on NON_COMPLIANT) for self-healing.

Amazon Detective for Cross-Service Correlation

Detective takes finding context further than Security Hub by building a behavior graph from CloudTrail, VPC Flow Logs, EKS audit logs, and GuardDuty findings. The graph models entities (users, roles, IPs, instances, accounts) as nodes and their interactions as edges, going back up to a year. When you click "Investigate in Detective" from a GuardDuty or Security Hub finding, you land on the entity profile with auto-generated panels: API call volume over time, geolocation of source IPs, services accessed, related findings.

Detective's killer feature on the exam is time-series investigation without writing queries. The graph is pre-built and continuously updated, so questions like "did this IAM role behave normally in the 7 days before the finding?" are answered in two clicks. Compare to Athena, where you must write SQL and join CloudTrail snapshots manually.

Athena Queries for Security Event Validation

Athena is the SQL-on-S3 query engine. For threat detection, three query targets matter:

1. CloudTrail logs — partition by /AWSLogs/<accountId>/CloudTrail/<region>/yyyy/mm/dd/. Use AWS-provided CloudTrail Glue table definition.
2. VPC Flow Logs — partition by date and account; use Apache Parquet format for 10× speed and cost reduction.
3. AWS Security Lake — the standardized OCSF (Open Cybersecurity Schema Framework) tables that aggregate CloudTrail, VPC Flow, Route 53, Security Hub, EKS audit, Lambda invocations across the org. Querying Security Lake means querying one canonical schema instead of N raw log formats.

Sample IOC validation queries every SCS-C02 candidate should recognize:

-- Find every API call made by a suspected compromised access key in the last 24 hours
SELECT eventTime, eventName, sourceIPAddress, userAgent, awsRegion, errorCode
FROM cloudtrail_logs
WHERE userIdentity.accessKeyId = 'AKIAIOSFODNN7EXAMPLE'
  AND eventTime > date_format(current_timestamp - interval '1' day, '%Y-%m-%dT%H:%i:%sZ')
ORDER BY eventTime;

-- Top external IPs talking to a compromised EC2 instance
SELECT srcaddr, sum(bytes) as total_bytes, count(*) as flow_count
FROM vpc_flow_logs
WHERE dstaddr = '10.0.42.17' AND srcaddr NOT LIKE '10.%'
  AND start > to_unixtime(current_timestamp - interval '24' hour)
GROUP BY srcaddr ORDER BY total_bytes DESC LIMIT 20;

CloudWatch Metric Filters and Anomaly Dashboards

When no managed service surfaces what you need, you fall back to CloudWatch metric filters and custom dashboards. A metric filter scans CloudWatch Logs entries against a JSON or text pattern and emits a custom metric every time the pattern matches.

Canonical security metric filters (CIS-recommended):

• Unauthorized API calls — pattern { ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") } against a CloudTrail Logs group.
• Sign-in without MFA — { ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") }.
• Root account usage — { $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }.
• IAM policy changes — pattern matching DeleteGroupPolicy, DeleteRolePolicy, PutUserPolicy, etc.
• Security group changes — AuthorizeSecurityGroup*, RevokeSecurityGroup*, CreateSecurityGroup, DeleteSecurityGroup.

Each filter feeds a CloudWatch metric, then a CloudWatch alarm fires on threshold breach, then SNS or EventBridge notifies the SOC. Layer CloudWatch anomaly detection on top: instead of a static threshold, the alarm uses a machine-learned model of normal hourly behavior. Useful for "API call volume spiked unusually" without manual baseline tuning.

Centralizing Findings: Security Hub as the Hub

The recurring exam pattern: "you have GuardDuty findings in 8 accounts and 4 regions, plus Macie findings in 2 accounts, plus Inspector findings in 12 accounts. The CISO wants a single dashboard." Answer:

1. AWS Organizations with all accounts joined.
2. Designate one security tooling account (per AWS SRA).
3. From the management account, register the security tooling account as delegated administrator for GuardDuty, Security Hub, Macie, Inspector, IAM Access Analyzer, and Detective.
4. In the security tooling account, auto-enable each service for new and existing org accounts.
5. Configure Security Hub cross-region aggregator to a chosen home region.
6. Enable FSBP standard at minimum, plus CIS / NIST / PCI as required.
7. Build CloudWatch dashboards or Amazon QuickSight on top of Security Hub findings exported via EventBridge to S3.

Threat Detection in Multi-Account Organizations

Beyond delegated admin, multi-account threat detection has three additional patterns the exam loves:

• Organization trail — a single CloudTrail trail at the organization level captures every member account's events into one S3 bucket. Cannot be disabled or modified by member accounts. This is the only architecture acceptable on the exam for "centralized CloudTrail".
• Config aggregator — collects Config configuration items and rule evaluations across all accounts and regions into a single aggregator account. Pair with Security Hub for organization-wide compliance scoring.
• Security Lake subscriber accounts — the security tooling account becomes a Security Lake subscriber and grants downstream consumers (SOC analysts via Athena, partner SIEMs via Lambda subscription) read-only access to OCSF-normalized data.

EventBridge as the Detection-to-Response Bridge

Every detection service publishes findings to Amazon EventBridge by default:

• GuardDuty → aws.guardduty source, GuardDuty Finding detail-type.
• Security Hub → aws.securityhub, Security Hub Findings - Imported (new findings) and Security Hub Findings - Custom Action (analyst-triggered).
• Macie → aws.macie, Macie Finding.
• Inspector → aws.inspector2, Inspector2 Finding.
• Config → aws.config, Config Rules Compliance Change.

Build EventBridge rules to fan out findings to:

• SNS topic for human-readable email/SMS to the SOC.
• Lambda function for custom triage logic (auto-tag, auto-isolate).
• Step Functions state machine for multi-step playbooks.
• Systems Manager Automation for predefined runbooks (e.g., quarantine EC2).
• Cross-account IAM role for routing to a partner SIEM.

Tuning Detection: Reducing False Positives Without Losing Signal

A noisy detection pipeline is worse than no pipeline because the SOC starts ignoring alerts. Tuning patterns the exam tests:

• GuardDuty suppression rules for known-good attribute combinations (developer workstation IP doing port scans against test infra).
• GuardDuty trusted IP lists for corporate VPN egress.
• Security Hub automation rules to lower severity on tagged dev/sandbox accounts.
• Macie allow lists to exclude known false-positive object patterns (sample data, demo CSVs).
• Inspector suppression rules by CVE + resource tag.
• Config rule scope to specific resource types or tag filters.
• CloudWatch composite alarms to require multiple simultaneous conditions before paging.

Common Exam Traps

• GuardDuty does not require enabling CloudTrail or VPC Flow Logs. It reads them via private feeds. Enabling those services separately gives you logs for Athena/CloudWatch but does not affect GuardDuty.
• Security Hub is regional. A single account with workloads in 4 regions needs Security Hub in all 4 regions plus an aggregator.
• Inspector v2 (Inspector) is different from Inspector Classic. The current Inspector scans EC2, ECR, and Lambda continuously and publishes to Security Hub. Inspector Classic is deprecated.
• Macie automated discovery is org-wide and free for the first 30 days. After that, charges per GB scanned. The full classification job is a separate billed line item.
• IAM Access Analyzer findings auto-resolve when the underlying policy changes. Do not write Lambda to clean them up.
• Detective requires GuardDuty enabled for at least 48 hours before activation in a region. The behavior graph builds from GuardDuty's CloudTrail/VPC/DNS feed.
• Athena queries on CloudTrail buckets require a Glue table. Use the AWS-provided template; manual schema authoring is error-prone.
• CloudWatch metric filters do not retroactively process old log lines. They apply only to logs ingested after the filter is created.

Decision Framework: Which Service Detects What?

Use this table on the exam when stems describe a detection need:

Cost Considerations

Detection services are usage-priced. Rough mental model for the exam (do not memorize exact rates):

• GuardDuty foundational — per million CloudTrail events, per GB of VPC Flow Logs, per million DNS queries. Protection plans add per-resource costs (Runtime Monitoring per vCPU-hour, S3 Protection per million S3 events).
• Security Hub — per finding ingested + per security check evaluated. Most expensive in noisy accounts.
• Macie — per GB scanned (full classification jobs) + per S3 bucket evaluated (automated discovery).
• Inspector — per resource (EC2, ECR image, Lambda) per month.
• Detective — per GB of ingested logs.
• Athena — per TB scanned (use Parquet/partitioning to slash cost).

Hands-On Practice Lab Sketch

To cement everything, run this lab in a sandbox account before the exam:

1. Enable GuardDuty + S3 Protection + Malware Protection.
2. Enable Security Hub with FSBP and CIS v3.0.0.
3. Enable Macie with automated discovery.
4. Enable IAM Access Analyzer (External + Unused).
5. Enable Inspector for EC2/ECR.
6. Enable Detective.
7. Generate test findings using the GuardDuty aws guardduty create-sample-findings API.
8. Watch findings flow into Security Hub.
9. Click "Investigate in Detective" on one finding.
10. Write an Athena query against your CloudTrail bucket joining the finding's principal ID to API call history.
11. Build a CloudWatch metric filter for unauthorized API calls; trigger it with a deliberate AccessDenied call.
12. Create an EventBridge rule that routes high-severity GuardDuty findings to an SNS topic.
13. Create a Security Hub automation rule that bumps severity for findings on resources tagged env=prod.

FAQ

Q1: When should I use Detective instead of Athena for investigation? Use Detective when you need a pre-built, time-series, entity-relationship view without writing SQL. The behavior graph aggregates CloudTrail, VPC Flow, EKS audit, and GuardDuty findings into entity profiles. Use Athena when you need a precise, ad-hoc query (e.g., "every event where this access key called s3:DeleteObject"), need to JOIN with non-AWS data, or need to query Security Lake's OCSF schema across many accounts. Many SCS-C02 questions present both as options; the discriminator is "low operational overhead, visual investigation" → Detective; "specific SQL question, large data, custom" → Athena.

Q2: Does enabling GuardDuty automatically enable Security Hub or vice versa? No. Each service is enabled independently. However, when both are enabled in the same account and region, GuardDuty findings flow to Security Hub automatically through the integration. The same is true for Macie, Inspector, IAM Access Analyzer, and AWS Config. Disabling the integration in Security Hub stops aggregation but does not stop the source service from generating findings.

Q3: How do I share GuardDuty findings with a partner SIEM (e.g., Splunk, Datadog)? Three patterns: (1) EventBridge rule on aws.guardduty source forwarding to Lambda → SIEM HTTP API, (2) Security Hub partner integration if your SIEM is on the supported list, (3) Security Hub findings export via EventBridge to S3 then ingested by the SIEM. The exam-preferred pattern is Security Hub aggregation in ASFF, then EventBridge to the SIEM. This avoids per-service custom plumbing.

Q4: What is the difference between a GuardDuty suppression rule and a Security Hub finding suppression? A GuardDuty suppression rule archives matching findings at the GuardDuty layer, so they never reach Security Hub. A Security Hub finding suppression uses workflow status SUPPRESSED set via BatchUpdateFindings or automation rules; the finding still exists in Security Hub but is hidden from default views. Use GuardDuty suppression when a finding type is unconditionally noise; use Security Hub suppression when you want the finding visible to auditors but excluded from active queues.

Q5: How do I detect S3 buckets containing PII without scanning the entire bucket every day? Enable Macie automated sensitive data discovery at the organization level. It samples objects across all S3 buckets continuously and produces sensitivity scores plus policy/sensitive-data findings. For exhaustive scanning of specific buckets, schedule classification jobs monthly or quarterly. The combination — always-on sampling + periodic deep scan — is the SCS-C02 best practice for sensitive data threat detection.

Q6: Can I use CloudWatch metric filters on VPC Flow Logs? Yes, if VPC Flow Logs are sent to a CloudWatch Logs group (not S3). Pattern-match on rejected traffic, specific source IPs, or unusual ports. However, GuardDuty already analyzes VPC Flow Logs natively and produces higher-quality findings; metric filters are best reserved for custom thresholds GuardDuty does not surface. For high-volume flow data, send to S3 instead and query with Athena.

Q7: What is the AWS Security Finding Format (ASFF) and why does it matter? ASFF is the standardized JSON schema for security findings on AWS. It defines fields like Severity, Resources[], Types[], ProductFields, Workflow.Status, and RecordState. Every native and partner integration with Security Hub publishes via the BatchImportFindings API in ASFF. The exam tests ASFF whenever the stem mentions "centralize findings from a third-party tool" or "build a custom security service that shows up in Security Hub." Answer: emit ASFF.

Q8: Should I enable all Security Hub standards or just FSBP? Start with FSBP — it is AWS-curated and covers the most common misconfigurations. Add CIS v3.0.0 if you have a CIS audit obligation, PCI DSS if you process card data, NIST 800-53 if you serve US federal customers. Each enabled standard increases finding volume and cost; enable only what your compliance program requires. The exam frequently asks "which standard satisfies requirement X" — memorize the four major frameworks and their use cases.

Q9: How does IAM Access Analyzer differ from the IAM Policy Simulator? Access Analyzer is detection — it finds existing exposures (external principals with access, unused permissions) by analyzing policies at rest. Policy Simulator is testing — you give it a principal, action, resource, and context, and it tells you whether the request would be allowed by current policies. Use Access Analyzer for continuous monitoring; use Policy Simulator for "will this proposed policy work?" pre-flight checks. They are complementary, not interchangeable.

Q10: What happens to Security Hub findings when an account leaves the organization? The delegated administrator loses visibility into that account's future findings. Existing aggregated findings remain in the security tooling account's Security Hub finding store but become read-only with respect to the source account. Re-onboarding the account does not re-import historical findings; it resumes aggregation from the re-onboarding moment forward. Plan account departures carefully if you need ongoing audit history.

Summary and Next Steps

Threat detection on AWS is a layered pipeline, not a single service. GuardDuty handles behavioral and threat-intel detection on CloudTrail, VPC Flow, DNS, and optional protection plans. Security Hub aggregates findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, Config, and partners — and runs continuous compliance standards (FSBP, CIS, PCI, NIST). Macie tackles sensitive-data threat detection on S3. IAM Access Analyzer detects permission exposure (external access) and dormancy (unused access). AWS Config supplies configuration-state findings. Detective accelerates investigation via behavior graphs. Athena validates events against Security Lake or raw logs. CloudWatch metric filters and dashboards catch what nothing else surfaces.

For SCS-C02 task statement 1.2, the meta-skill is service selection under constraint: given a scenario stem, pick the smallest set of services that achieves detection with appropriate operational overhead, cost, and integration depth. Practice the decision table above until it is reflex. Then move on to task statement 1.3 (response automation) — Security Hub findings are useless if they do not trigger remediation. Threat detection is the input; incident response is the output.