SCS-C02 Threat Detection and Incident Response Practice Question

A company has a multi-account AWS environment with hundreds of accounts. The security team needs to ensure that all security findings from GuardDuty, Security Hub, and Detective are centrally collected and correlated. Which architecture is the MOST scalable and cost-effective?

⚠ Common exam trap

The trap here is that candidates may over-engineer a solution with Lambda, DynamoDB, or S3/Athena, overlooking that Security Hub's built-in cross-account aggregation is the simplest, most scalable, and most cost-effective approach for centralizing security findings.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable AWS Security Hub as the central aggregator, with GuardDuty and Detective integrated. Use Security Hub cross-account aggregation.

AWS Security Hub natively supports cross-account aggregation via a delegated administrator, allowing findings from GuardDuty, Security Hub, and Detective to be centrally collected without custom code. This architecture is both scalable (handles hundreds of accounts without polling or custom infrastructure) and cost-effective (no additional Lambda, DynamoDB, or S3 query costs), leveraging built-in integrations and consolidated findings views.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Deploy a central Lambda function that polls each account's GuardDuty, Security Hub, and Detective APIs and stores findings in DynamoDB.
Why it's wrong here
A single Lambda polling every account pays a heavy tax at scale: it must assume roles into each account, call GuardDuty, Security Hub, and Detective APIs, then handle pagination, throttling, and eventual consistency across hundreds of accounts. Storing the resulting snapshots in DynamoDB only gives point-in-time data, and there is no built-in normalization or deduplication, so you essentially reinvent Security Hub's aggregation layer with brittle custom code. Polling also introduces latency and creates an external dependency for security monitoring.
✓
Enable AWS Security Hub as the central aggregator, with GuardDuty and Detective integrated. Use Security Hub cross-account aggregation.
Why this is correct
Security Hub natively acts as the central aggregator by ingesting GuardDuty findings and Detective investigation data as standard findings in the AWS Security Finding Format. Once you designate an administrator account and enable cross-account aggregation via AWS Organizations, all member accounts' findings flow into one dashboard with automatic deduplication, enrichment, and integration with EventBridge for remediation. This purpose-built architecture scales to hundreds of accounts without custom polling or log shipping.
✗
Configure each account to send findings to a central CloudWatch Logs log group and use CloudWatch Logs Insights to correlate.
Why it's wrong here
CloudWatch Logs is a log storage and query solution, not a security finding pipeline; sending GuardDuty or Security Hub findings to a central log group requires per-account subscription filters and a cross-account destination, adding operational overhead. CloudWatch Logs Insights can search for specific log patterns but cannot correlate findings across accounts or services in real time, nor does it provide the structured finding metadata, severity, and compliance info that Security Hub maintains. You would also have to build custom alerting on top of logs, whereas Security Hub provides built-in automated response and posture management.
✗
Stream all findings from all services to a central Amazon S3 bucket and use Amazon Athena to query them.
Why it's wrong here
Writing raw findings to S3 creates an archive that you can query with Athena, but Athena runs only when you invoke it, so it does not provide continuous, real-time correlation or notification. Each query must re-parse potentially millions of JSON files and join them manually across services, and you'd need Glue tables and partition management just to maintain basic schema consistency. Athena is useful for forensic analysis, but it cannot replace Security Hub's native cross-account aggregation, automatic severity normalization, and integration with Detective for root-cause investigation.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question