Security Monitoring — CloudTrail, GuardDuty, Security Hub, and Macie

CloudTrail, GuardDuty, and Security Hub form the audit and detection trinity that makes a multi-account AWS Organization observable, investigable, and provable to auditors. On the DOP-C02 exam, CloudTrail, GuardDuty, and Security Hub appear all over Domain 6 Task 6.3 whenever a scenario sets "produce immutable audit trail across 50 accounts," "detect compromised IAM credentials and crypto-mining," "aggregate findings from 5 security services into one dashboard," or "auto-remediate any GuardDuty high-severity finding." The right answer always combines an organization-wide CloudTrail trail (for who-did-what), GuardDuty (for ML-driven threat detection), and Security Hub (for finding aggregation and standards compliance) into a coordinated detection-and-response stack with EventBridge as the glue and the Audit account as the operator.

This Pro-depth guide walks through every CloudTrail GuardDuty Security Hub primitive you will encounter on DOP-C02: organization trails delivering to Log Archive, CloudTrail Lake's SQL engine and 10-year retention, CloudTrail Insights anomalous-activity detection, GuardDuty's three protection plans (S3, EC2 Malware, EKS) and finding categories, Security Hub's AWS Security Finding Format (ASFF), cross-region finding aggregation, automation rules, the delegated-admin pattern, EventBridge as the trigger fabric for auto-remediation, finding suppression and workflow status management, and the canonical Pro scenario — fleet-wide threat detection with auto-quarantine on critical findings — dissected step by step.

What Are CloudTrail GuardDuty and Security Hub?

CloudTrail records every AWS API call across an account or organization to S3, CloudWatch Logs, and CloudTrail Lake — the immutable audit log. GuardDuty is a managed threat-detection service that uses machine learning and threat intelligence to identify malicious activity in CloudTrail events, VPC Flow Logs, DNS logs, EKS audit logs, and S3 data events — the threat sensor. Security Hub is the cross-service finding aggregator that collects findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, AWS Config rules, Firewall Manager, Health, and 50+ third-party tools, normalizes them into the AWS Security Finding Format, and runs compliance standards like CIS, PCI-DSS, and NIST 800-53.

Why CloudTrail GuardDuty and Security Hub Matter for DOP-C02

DOP-C02 Task 6.3 explicitly demands "AWS CloudTrail," "Amazon GuardDuty," and the ability to "implement security monitoring and auditing solutions." Pro-tier scenarios bundle all three with EventBridge-driven automated response across 50-account organizations. Single-service answers are usually distractors; the exam tests knowing when each service contributes and how they integrate.

The Detection Lifecycle

Understanding CloudTrail GuardDuty and Security Hub requires holding the detection lifecycle in your head: collect (CloudTrail records, VPC Flow Logs flow, DNS queries log) → detect (GuardDuty analyses, Config evaluates, Inspector scans, Access Analyzer evaluates) → aggregate (Security Hub normalizes to ASFF) → respond (EventBridge invokes Lambda, SSM Automation, SNS) → investigate (CloudTrail Lake SQL, Athena over flow logs, Detective behaviour graphs) → prove (audit evidence package). Every pro-tier security scenario walks one or more legs of this lifecycle.

Plain-Language Explanation: CloudTrail GuardDuty and Security Hub

CloudTrail GuardDuty and Security Hub sound like another acronym soup, but three everyday analogies expose their roles.

Analogy 1 — The Bank Branch Surveillance and Fraud Detection System (Banking Analogy)

Picture a bank with 50 branches (your AWS accounts), one central security operations centre (Audit account), and one immutable evidence vault (Log Archive account). CloudTrail GuardDuty Security Hub is the layered surveillance and fraud-detection system.

The CCTV recordings of every transaction captured at every teller window of every branch and shipped to the central evidence vault is CloudTrail — every API call across every account streams to one S3 bucket plus CloudTrail Lake. The recordings are signed, immutable, retained 10 years. The fraud-detection AI that watches transaction patterns 24/7 — flagging "this customer never withdraws cash from Lagos but just wired $10,000 there at 3 AM" — is GuardDuty: it consumes the same surveillance feeds (CloudTrail + VPC Flow Logs + DNS + EKS audit) and emits findings when behaviour deviates from baseline. The central security dashboard that aggregates fraud alerts from the AI, suspicious-activity reports from compliance scanners (Inspector vulnerability scans, Macie sensitive-data discovery), and regulatory-compliance scores (CIS, PCI-DSS standards) into one screen for the SOC supervisor is Security Hub — it collects findings from GuardDuty, Inspector, Macie, Access Analyzer, Config, and third-party tools, normalizes them to one schema (ASFF), and presents a unified dashboard. The escalation playbook that says "any critical fraud alert must auto-freeze the account and SMS the supervisor" is EventBridge → Lambda → IAM AttachUserPolicy(Deny) automation. The forensic investigator running SQL queries like "show me every transaction by user X across all branches in the past 90 days" is CloudTrail Lake. The regulatory examiner's annual audit package is the evidence drawn from the Log Archive vault. Three services, one detection-and-response system, one operations centre.

Analogy 2 — The Hospital Infection Control and Audit System (Hospital Analogy)

Imagine a hospital network with 50 sites (your AWS accounts), one central infection-control unit (Audit account), and one regulatory medical-records archive (Log Archive account). CloudTrail GuardDuty Security Hub is the layered audit and infection-detection system.

The continuous medical-records logging capturing every prescription, procedure, and lab order across every site and shipping to the regulatory archive is CloudTrail — every API action recorded, signed, retained for compliance. The infection-control screening AI that watches admission patterns and flags "this site had 5 unusual antibiotic-resistant cases in 24 hours" is GuardDuty — it watches the same record stream plus network flow and DNS queries, applies threat intelligence and ML models, and emits findings on anomalies. The central infection-control dashboard rolling up screening alerts, antibiotic stewardship scores (Inspector-style vulnerability scans), patient-data-handling compliance (Macie sensitive-data findings), and overall accreditation status (CIS / Joint Commission standards) is Security Hub — one normalized format (ASFF), one cross-site dashboard, one workflow status per finding. The automatic isolation protocol that triggers when a critical infection finding fires — automatically quarantines the affected ward — is EventBridge → Lambda → SSM Automation that, in AWS terms, isolates a compromised EC2 with a deny-all security group. The forensic infection-source tracing running SQL queries over years of records is CloudTrail Lake. The regulatory accreditation package for Joint Commission inspection is the Log Archive evidence. Three services, one continuous detection system, one infection-control unit operating from one delegated admin.

Analogy 3 — The Airport Customs and Security Screening Network (Airport Analogy)

Picture a national airport authority with 50 airports (your AWS accounts), one central security operations centre (Audit account), and one investigations records vault (Log Archive account). CloudTrail GuardDuty Security Hub is the integrated security network.

The customs and immigration entry log recording every passenger's passport scan at every airport and shipping to the central investigations vault is CloudTrail — every entry/exit, signed, retained for years. The behaviour-analysis system that watches passenger patterns and flags "this passport was used to enter through Frankfurt 2 hours ago, impossible to also be entering Madrid now" is GuardDuty — it watches the same passport-scan stream plus baggage-handling network flow and contact-list DNS queries, applies threat-intelligence feeds (suspect names, known-bad IPs in AWS terms), and emits findings on anomalies. The central operations dashboard showing security alerts from immigration, baggage scanning vulnerabilities (Inspector-style), restricted-item discoveries (Macie-style sensitive-data findings), and overall airport accreditation status (CIS / TSA / IATA standards) is Security Hub — one ASFF schema, one cross-airport view. The automatic gate-closure protocol when a critical finding fires — automatically locks down the affected zone — is EventBridge → Lambda → SSM Automation. The investigation desk running SQL queries like "every entry by passport X across all airports in the past 12 months" is CloudTrail Lake. The annual security accreditation evidence package is from Log Archive. Three services, one detection-and-response system, one operations centre, automated quarantine for critical findings.

CloudTrail Organization Trail — The Foundation of Audit

CloudTrail is the first thing you enable in every AWS account, and DOP-C02 expects this in every audit scenario.

Organization Trail Mechanics

An organization trail is a single CloudTrail trail created from the management account or CloudTrail delegated admin that auto-applies to every current and future member account in every region. Member accounts cannot disable or modify the organization trail from their own consoles — only the management/delegated admin can. The trail delivers to one S3 bucket in the Log Archive account.

Management Events vs Data Events vs Insights Events

CloudTrail records three event classes:

• Management events (free first copy, included in every trail): control-plane API calls — RunInstances, CreateRole, PutBucketPolicy. Always on by default.
• Data events (paid): data-plane activity — every S3 GetObject and PutObject, every Lambda Invoke, every DynamoDB item-level access. Off by default. Pro-tier audit setups enable on sensitive S3 buckets, all Lambda, and regulated DynamoDB tables.
• Insights events (paid add-on): anomalous patterns in management events. CloudTrail Insights detects unusual call rates and emits Insights findings into the trail.

S3 Delivery and Bucket Hardening

The Log Archive S3 bucket needs:

• Bucket policy granting cloudtrail.amazonaws.com PutObject with aws:SourceArn pinned to the trail ARN (confused-deputy protection)
• Default SSE-KMS encryption with an Organization-shared CMK
• Versioning enabled
• Block all public access
• S3 Object Lock in Compliance mode for regulatory retention (often 7 or 10 years)
• MFA delete on root

Log File Integrity Validation

CloudTrail produces hourly digest files signed with SHA-256/RSA, allowing cryptographic verification that log files were not altered. Always enable on every centralized audit trail — auditors expect it, and signed log files are admissible evidence.

CloudTrail Lake — SQL on Top of CloudTrail

CloudTrail Lake is the newer SQL-queryable event data store. Organization-level event data store ingests every management/data/Insights event from every member account in every region. Retention configurable up to 10 years. Immutable. Apache Presto-style SQL.

Typical Pro-tier queries:

• "Find every AssumeRole from a specific source IP across all accounts in the last 30 days"
• "List every DeleteObject on any bucket tagged Compliance=HIPAA over the past year"
• "Show every root ConsoleLogin across the organization"
• "Identify all CreateAccessKey events where the principal had not previously created keys"

These queries would be painful on raw S3+Athena without partition tuning; CloudTrail Lake returns answers in seconds.

CloudTrail Insights — Anomalous API Activity Detection

CloudTrail Insights is the under-utilized capability DOP-C02 frequently tests as a distractor against GuardDuty.

What Insights Does

Insights analyses management events for anomalous patterns — sudden spikes in DeleteObject, unusual concentration of AssumeRole, unexpected region usage. Findings are recorded as Insights events in the trail's S3 destination. Each Insights event includes the API name, the baseline rate, the observed rate, and the time window.

Insights vs GuardDuty

Both detect anomalies but on different signals:

• Insights: API call rate anomalies (one specific API spiking).
• GuardDuty: behaviour-based threat detection (compromised credentials, crypto-mining, malware C2, port scanning).

DOP-C02 scenarios use them together. Insights catches "weird call rate"; GuardDuty catches "this looks like credential compromise."

GuardDuty — ML-Driven Threat Detection

GuardDuty is the threat-detection workhorse. DOP-C02 expects detail.

What GuardDuty Analyzes

GuardDuty consumes (without you configuring delivery):

• VPC Flow Logs
• CloudTrail management and data events
• DNS query logs (Route 53 Resolver)
• EKS audit logs (with EKS Protection enabled)
• S3 data events (with S3 Protection enabled)
• EBS volumes (with Malware Protection scanning)
• RDS login activity (with RDS Protection enabled)
• Lambda network activity (with Lambda Protection enabled)

GuardDuty does not require you to ship logs anywhere — it taps the sources directly, eliminating data-pipeline overhead.

Finding Categories

GuardDuty findings span dozens of types under categories:

• Backdoor/CryptoCurrency — instance contacting known crypto-mining domains.
• CredentialAccess — API calls suggesting compromised credentials (anomalous geo, anomalous user-agent).
• DefenseEvasion — disabling CloudTrail, removing security group rules.
• Discovery/Reconnaissance — port scanning, IAM enumeration.
• Exfiltration — anomalous outbound traffic, S3 data access from unusual sources.
• Impact — DDoS, ransomware-style behaviour.
• InitialAccess — login attempts from Tor, brute-force SSH/RDP.
• PrivilegeEscalation — IAM policy modification, role-assumption chains.

Each finding has severity (low / medium / high) and includes the resource, principal, threat-list match, and recommended remediation.

Multi-Account Enablement

Designate a delegated administrator (Audit account). From the delegated admin, enable GuardDuty across every member account in every region with auto-enable for new accounts. Findings from all members flow to the delegated admin's view. Each member retains their own copy too, but cross-account aggregation lives in the delegated admin.

Suppression Rules and Trusted Lists

GuardDuty supports:

• Suppression rules — auto-archive findings matching criteria (e.g., "suppress all findings on this VPC where the principal is the security-scan service"). Reduces noise without disabling detection.
• Trusted IP lists — IPs you trust; GuardDuty does not generate findings on them.
• Threat IP lists — additional IPs you consider malicious; GuardDuty generates findings on traffic from them beyond its built-in feeds.

EventBridge Integration — The Action Layer

Every GuardDuty finding emits an EventBridge event in the source account. Pattern: EventBridge rule filters on finding severity ≥ 7 → invokes Lambda → Lambda quarantines the affected EC2 by attaching a deny-all security group, isolates the IAM credential by attaching a deny-all policy, and posts to PagerDuty/Slack. This is the canonical DOP-C02 auto-remediation flow.

GuardDuty Protection Plans — Pay-for-Coverage Modules

DOP-C02 expects awareness of GuardDuty's optional plans.

S3 Protection

Enabled by default in newly enabled GuardDuty accounts (after 2020). Detects anomalous S3 object access patterns — credential compromise reading sensitive S3 objects, anomalous geography, anomalous behaviour from a previously-trusted principal.

EKS Protection (Audit Logs)

Consumes the EKS control-plane audit log. Detects anomalous Kubernetes API patterns — privilege escalation, unauthorized exec into pods, suspicious workloads, container breakouts.

Runtime Monitoring (EKS, ECS, EC2)

Lightweight agent runs in EKS/ECS/EC2 to capture process and file activity. Detects in-container malicious behaviour (cryptominer process, reverse shells, file system modifications). Newer than audit-log-only protection; significantly more sensitive.

Malware Protection for EC2

GuardDuty automatically snapshots EBS volumes attached to suspicious EC2 instances and scans them for malware. No agent needed. Findings include the file path and malware signature.

RDS Protection

Detects anomalous database login attempts to RDS Aurora MySQL/PostgreSQL — brute force, anomalous geography, credential compromise.

Lambda Protection

Detects anomalous network activity from Lambda functions — exfiltration to known-bad IPs, contacting crypto-mining infrastructure.

Each plan adds cost; all are off-by-default in older GuardDuty accounts and on by default in new ones. DOP-C02 may test naming each plan and what it covers.

Security Hub — Aggregation, Standards, and Automation

Security Hub is the unified pane of glass that DOP-C02 expects you to use as the SOC dashboard.

What Security Hub Aggregates

Findings from:

• Amazon GuardDuty
• Amazon Inspector
• Amazon Macie
• IAM Access Analyzer
• AWS Firewall Manager
• AWS Health
• AWS Config (via standards)
• AWS Systems Manager Patch Manager
• 50+ third-party tools (Palo Alto, Tenable, CrowdStrike, Splunk, etc.)

All normalized to AWS Security Finding Format (ASFF), a JSON schema with consistent fields (SeverityLabel, ResourceArn, WorkflowStatus, RecordState, ProductFields, Compliance).

ASFF Format

ASFF unifies findings across products. A GuardDuty finding and a Tenable.io finding both have Severity.Label, Resources[].Id, WorkflowStatus, etc. SOC analysts query/filter by these fields without knowing the source product. ASFF supports custom findings — push organisation-specific findings via BatchImportFindings API.

Security Hub Standards

Pre-built compliance frameworks deployed as Security Hub controls:

• AWS Foundational Security Best Practices (AFSBP)
• CIS AWS Foundations Benchmark v1.2 / v1.4 / v3
• PCI-DSS v3.2.1 / v4
• NIST 800-53 Rev 5

Each standard maps to underlying Config rules. Enabling a standard auto-deploys the rules. Disabling a control suppresses its findings without touching the underlying rule (preventing duplicate work with Config conformance packs).

Cross-Region Finding Aggregation

Designate one region as the aggregation region. Findings from every other region flow to the aggregation region for unified search and dashboarding. Critical for global organisations — a SOC analyst in us-east-1 sees findings from ap-southeast-2 and eu-west-1 without switching consoles.

Multi-Account Delegated Admin

Same pattern as GuardDuty. Audit account is the Security Hub delegated admin. Member accounts auto-enroll. Findings aggregate to the delegated admin's view across all accounts and all regions.

Workflow Status

Each finding has a WorkflowStatus: NEW / NOTIFIED / RESOLVED / SUPPRESSED. SOC analysts triage by changing status. RecordState: ACTIVE / ARCHIVED — automatically set by source products.

Automation Rules

Security Hub Automation Rules (announced 2023) let you automatically modify findings — set severity, suppress, change workflow — based on filter criteria. Replaces hand-rolled EventBridge → Lambda for simple finding-triage logic.

EventBridge as the Glue — Detection to Action

EventBridge is the trigger fabric DOP-C02 expects in every detection-to-action scenario.

Pattern: Finding to Lambda to Remediation

GuardDuty finding
  → CloudWatch Events / EventBridge default bus
  → EventBridge rule (filter on severity ≥ HIGH, type contains "UnauthorizedAccess")
  → Lambda invocation
  → Lambda calls EC2 ModifyInstanceAttribute / IAM AttachUserPolicy / SSM Automation
  → Notify SNS / Slack / PagerDuty

Pattern: Security Hub Finding to Step Functions

For complex remediation requiring approval:

Security Hub finding (ASFF format)
  → EventBridge rule
  → Step Functions state machine
  → Manual approval task (SNS to security team)
  → Conditional remediation
  → Update finding workflow status to RESOLVED

Cross-Account EventBridge

EventBridge supports cross-account event delivery. Member account's GuardDuty finding can be routed to the Audit account's EventBridge bus, where central remediation logic operates. Avoids deploying remediation Lambdas in every member account.

Detective — When Investigation Goes Deeper

Amazon Detective is the often-forgotten member of the security suite that DOP-C02 occasionally tests.

What Detective Does

Detective ingests CloudTrail, VPC Flow Logs, GuardDuty findings, EKS audit logs and builds a behavioral graph showing relationships between IAM principals, EC2 instances, IP addresses, and resources. Investigators ask "what did this principal do across all my accounts?" and get a visual graph.

When to Use Detective

After a GuardDuty finding fires, the SOC analyst clicks through to Detective for investigation. "This IAM user was flagged for credential compromise; show me everything they touched in the past 30 days, including resources I did not initially suspect." Detective's behavior graph beats SQL queries for relationship-traversal investigation.

Detective vs CloudTrail Lake

CloudTrail Lake: SQL on events. Detective: graph on behaviors. Different tools, different questions. Use Lake for "give me every API call matching X"; use Detective for "show me the relationship graph around this finding."

The Canonical Pro Scenario — Fleet-Wide Threat Detection with Auto-Quarantine

Putting it all together, the canonical DOP-C02 scenario.

Architecture

• Log Archive account: organization-wide CloudTrail trail with Object Lock; CloudTrail Lake org event data store with 10-year retention.
• Audit account: GuardDuty delegated admin with auto-enable; Security Hub delegated admin with cross-region aggregation; Detective delegated admin; Inspector delegated admin; Access Analyzer delegated admin.
• Member accounts: GuardDuty enabled with all protection plans; Security Hub enabled with AFSBP and CIS standards; Inspector enabled for EC2/ECR/Lambda.

Auto-Remediation Flow

1. GuardDuty in member account detects UnauthorizedAccess:IAMUser/MaliciousIPCaller.
2. Finding flows to Audit account Security Hub via delegated admin.
3. Audit account EventBridge rule filters on severity ≥ HIGH + matching pattern.
4. Lambda in Audit account assumes a remediation role in the member account, attaches a Deny * policy to the suspect IAM user, snapshots the affected EC2.
5. SNS publishes to Slack #security-incidents and PagerDuty.
6. Security Hub Automation Rule sets workflow status to NOTIFIED.

Investigation Flow

1. Analyst opens the finding in Security Hub Audit account dashboard.
2. Clicks through to Detective behaviour graph.
3. Runs a CloudTrail Lake SQL query for full historical context.
4. Confirms incident, updates Security Hub workflow to RESOLVED with comment.

常考陷阱 (Common Exam Traps)

DOP-C02 has predictable CloudTrail GuardDuty Security Hub gotchas:

1. Per-account CloudTrail trails instead of organization trail — wrong. Org trail auto-onboards new accounts; per-account trails do not.
2. CloudTrail data events disabled in audit scenarios requiring S3 / Lambda visibility — data events must be explicitly enabled (extra cost). Default-on is management events only.
3. Single-region GuardDuty / Security Hub — must enable in every region where workloads run. Findings only generate in regions with the service enabled.
4. Confusing Insights with GuardDuty — Insights is API rate anomalies (one API spiking). GuardDuty is behaviour-based threat detection (compromise patterns, malware, exfiltration).
5. Security Hub aggregation region not configured — findings stay in their source region; SOC dashboards only see one region. Always set an aggregation region.
6. Forgetting Object Lock on Log Archive bucket — without it, a compromised admin can delete evidence. Compliance mode prevents even root from deleting.
7. Custom EventBridge rules in every account instead of cross-account routing — operational overhead. Route findings to the central Audit account bus for central remediation logic.
8. Inspector / Macie / Detective omitted in audit-coverage answers — full Pro coverage includes vulnerability scanning, sensitive-data discovery, and behaviour-graph investigation, not just GuardDuty + Security Hub.
9. Enabling Security Hub standards and Config conformance packs duplicating — same controls deployed twice means doubled Config evaluation cost. Pick one path per framework.
10. Failing to enable GuardDuty Protection plans (S3, EKS, Runtime, Malware, RDS, Lambda) when scenario mentions those resources — base GuardDuty does not cover them; enable the relevant plan.

FAQ

Q1: When do I use CloudTrail Lake vs S3 + Athena for audit queries? CloudTrail Lake: managed SQL engine, 10-year retention, simple setup, priced per GB ingested + per GB scanned. S3 + Athena: cheaper raw storage, requires partition tuning and Glue catalog, accessible to non-CloudTrail consumers. Most Pro-tier setups run both — Lake for active investigation, S3 for raw evidence and long-term cold storage.

Q2: How does GuardDuty differ from CloudTrail Insights? Insights detects anomalous management API call rates (one API spiking compared to baseline). GuardDuty detects threat behavior across CloudTrail + VPC Flow Logs + DNS + EKS + S3 + EBS using ML and threat intelligence. Insights catches "weird volume of CreateUser calls"; GuardDuty catches "this looks like credential compromise from a Tor exit node." They complement each other.

Q3: Should I aggregate findings into Security Hub or into a SIEM like Splunk? Both. Security Hub for AWS-native single-pane-of-glass, automation rules, standards compliance. Splunk/Datadog/Sentinel for cross-cloud correlation, longer retention, custom dashboards. Pattern: findings flow to Security Hub → Security Hub findings stream via EventBridge → Firehose → SIEM.

Q4: What's the right delegated admin for GuardDuty/Security Hub/Inspector? The same Audit account for all. Centralizing detective tooling delegated admins in one account reduces operational complexity and reuses the same IAM permissions, cross-region aggregation, and EventBridge buses. The management account should not be the delegated admin (kept minimal for security).

Q5: How do I auto-quarantine an EC2 instance flagged by GuardDuty? EventBridge rule filters on the relevant GuardDuty finding pattern → Lambda assumes a remediation role in the affected member account → Lambda calls ModifyInstanceAttribute to attach a quarantine security group with no inbound and no outbound. Snapshot the EBS volume with CreateSnapshot for forensics. Notify via SNS.

Q6: How long do GuardDuty findings retain? Active findings persist for 90 days from last update. Archived findings are removed. To retain longer, stream findings to Security Hub (also limited) and to S3 via EventBridge → Firehose → S3 (configurable lifecycle, can be years).

Q7: How does Security Hub work with AWS Organizations? Designate a member account as Security Hub delegated admin. From there, enable Security Hub across all member accounts in all regions with auto-enable for new accounts. Choose an aggregation region. Enable standards (AFSBP, CIS, PCI, NIST). All findings flow to the delegated admin's view across all members and regions.

Q8: Can I export Security Hub findings to my SIEM? Yes. Security Hub publishes findings to EventBridge by default. Configure a rule routing findings to Kinesis Data Firehose → S3 (for cold storage) or directly to a Splunk/Datadog/Sumo Logic destination. AWS partner products often have one-click integration.

Q9: What's the difference between Security Hub controls and Config conformance packs? Security Hub controls are pre-built, AWS-managed, mapped to popular standards (AFSBP, CIS, PCI, NIST). Conformance packs are customer-deployable bundles that can include managed Config rules, custom rules, and remediation actions. For popular frameworks, Security Hub is one-click. For custom baselines or remediation-attached compliance, conformance packs.

Q10: When should I use Detective vs CloudTrail Lake for investigation? Detective: relationship-graph view ("show me everything connected to this principal"). Best for incident-response storytelling. CloudTrail Lake: SQL queries on events ("give me every API call matching X over the past year"). Best for forensic data extraction. Use both — Detective for the story, Lake for the evidence.

Summary — CloudTrail GuardDuty Security Hub Mental Model

CloudTrail GuardDuty Security Hub is the audit-and-detection trinity for DOP-C02. CloudTrail provides the immutable trail of who-did-what; GuardDuty provides ML-driven threat detection across CloudTrail, VPC Flow Logs, DNS, EKS, S3, EBS, RDS, and Lambda; Security Hub aggregates findings from all detective tooling into one normalized ASFF-format dashboard with compliance standards on top. EventBridge glues findings to remediation actions. Detective adds behaviour-graph investigation; Inspector adds vulnerability scanning; Macie adds sensitive-data discovery; Access Analyzer adds external-access detection.

The mature DOP-C02 answer pattern is the delegated-admin model: Audit account runs GuardDuty/Security Hub/Inspector/Macie/Access Analyzer/Detective delegated admins; Log Archive account runs the org CloudTrail trail with Object Lock; member accounts auto-enroll; cross-region aggregation funnels everything to one pane of glass; EventBridge routes findings to Lambda or SSM Automation for self-healing on critical events. Single-account, single-service, single-region answers are Pro-tier distractors.