SCS-C02 Threat Detection and Incident Response Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Stream logs to Amazon Elasticsearch Service and use Kibana alerts

  Why it's wrong here

  Streaming logs to Amazon Elasticsearch Service (Amazon OpenSearch Service) and relying on Kibana alerts is not suitable for true real-time threat detection because ingestion is batch-oriented—for example, using Kinesis Firehose introduces a buffering window (default 1-5 minutes) and OpenSearch has an indexing refresh interval that delays document visibility. Additionally, Kibana alerting runs scheduled queries on already-indexed data, adding further latency. This means detection time is minutes behind the actual threat, which fails to meet a real-time response requirement.

• ✗

  Use S3 event notifications to trigger Lambda functions on new log files

  Why it's wrong here

  Using S3 event notifications to trigger Lambda functions on new log files assumes logs are already delivered to S3, but most logging services (CloudTrail, VPC Flow Logs, ELB logs) deliver files only after a frequency interval—typically 5 minutes to several hours—so the activity is not captured as it happens. Even when an event fires, the full file must be written first, and Lambda invocation adds cold-start overhead (sometimes 1-3 seconds), making the total end-to-end detection latency far too high for real-time threat response. This approach is best suited for asynchronous, post-processing tasks, not immediate detection.

• ✗

  Export logs to S3 and use Amazon Athena queries with scheduled rules

  Why it's wrong here

  Exporting logs to S3 and using Athena with scheduled rules is fundamentally a batch analysis model—Athena queries execute across objects in S3 and incur overhead for object discovery, file reading, and data scan; each query typically takes seconds to minutes, especially on large log datasets. Scheduled rules (e.g., via EventBridge Scheduler) run on a fixed cron-like interval, meaning threats can go undetected until the next schedule, and there is no event-driven trigger to initiate immediate action. Since Athena is pull-based and not streaming, it cannot detect anomalies as they occur, making it unsuitable for sub-minute detection and response.

• ✓

  Use Amazon Kinesis Data Analytics for real-time analysis and AWS Lambda for automated response

  Why this is correct

  Amazon Kinesis Data Analytics continuously processes streaming logs using SQL or Apache Flink, allowing pattern matching, anomaly detection, and aggregation over sliding windows in near-real-time—latency can be under a few seconds. It can output its results to a Lambda function (via a Kinesis Data Analytics destination or an intermediate Kinesis Data Stream) which then executes an automated response (e.g., updating security groups, invoking AWS WAF, or sending alerts). This stream-processing architecture directly meets the 'detect and respond' requirement with minimal delay, unlike batch-based alternatives.

Go deeper

Related to this question