SCS-C02 Threat Detection and Incident Response Practice Question
A company uses AWS Organizations with multiple accounts. The security team wants to centrally aggregate and analyze VPC Flow Logs from all accounts. Which solution is MOST efficient and scalable?
⚠ Common exam trap
Many exam-takers default to S3-based solutions (Option A) because they are familiar with S3 for log storage, but they overlook that Kinesis Data Firehose provides a more direct, serverless pipeline for real-time analysis without the latency and complexity of S3 replication.
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
✓
Configure VPC Flow Logs to send to Amazon Kinesis Data Firehose in each account, which delivers to a central Amazon OpenSearch Service domain.
Amazon Kinesis Data Firehose can directly receive VPC Flow Logs from each account and deliver them to a centralized Amazon OpenSearch Service domain, enabling near-real-time aggregation and analysis without intermediate storage or replication overhead. This architecture is serverless, scales automatically, and avoids the complexity of managing cross-account S3 replication or EC2 instances, making it the most efficient and scalable solution for centralized log analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure VPC Flow Logs to send to an S3 bucket in each account and use S3 Cross-Region Replication to a central bucket.
Why it's wrong here
Writing VPC Flow Logs to a regional S3 bucket and enabling S3 Cross-Region Replication only copies objects between buckets; it does not load the data into any analytics or search engine, so you cannot query the flow logs without separately running Athena or Glue jobs. Replication is asynchronous and eventually consistent, meaning real-time monitoring isn't possible, and any existing query setup must originate from the source account's bucket before replication. It also adds storage, replication, and lifecycle management complexity while delivering none of the integrated visualization and alerting capabilities of OpenSearch.
- ✗
Launch Amazon EC2 instances in each account to run tcpdump and send logs to a central S3 bucket.
Why it's wrong here
This approach relies on installing and continuously managing tcpdump agents on EC2 instances to capture network traffic, which adds CPU/memory overhead and operational burden in every account. It captures raw packet data only on the instances running the agent, so it cannot provide the account- and VPC-level network telemetry, security group, and subnetwork metadata that VPC Flow Logs include. The logs would require custom shipping to S3 and lack AWS's fully managed, scalable flow-log pipeline.
- ✗
Configure VPC Flow Logs to send to CloudWatch Logs in each account and use cross-account CloudWatch dashboards.
Why it's wrong here
Publishing VPC Flow Logs to CloudWatch Logs in each account enables per-account search, but cross-account dashboards merely project metrics/visuals from multiple CloudWatch Logs groups; they do not consolidate the raw logs into one searchable store, and you still have to manage each account's log retention and permissions. While CloudWatch Logs supports subscription filters for cross-account streaming, using only cross-account dashboards is not a central ingestion solution and creates scaling limits on high-volume log traffic. This option also requires custom dashboard setup and doesn't natively deliver to a centralized analytics engine like Amazon OpenSearch Service.
- ✓
Configure VPC Flow Logs to send to Amazon Kinesis Data Firehose in each account, which delivers to a central Amazon OpenSearch Service domain.
Why this is correct
VPC Flow Logs can be streamed directly to Amazon Kinesis Data Firehose in each account, and Firehose can then deliver nearly real-time data to a centrally owned Amazon OpenSearch Service domain cross-account. This is a fully managed, serverless pipeline that scales automatically with flow-log volume and avoids installing agents or operating log forwarders. A central OpenSearch cluster provides unified querying and visualization across all accounts' VPC traffic, making it the correct architecture for centralized real-time network analysis.
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
Related to this question
About these practice questions
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.