Detection
Detection is one pipeline with three jobs: generate the signal, act on it, fix it when it goes quiet
A SCS-C03 detection question almost always hands you a symptom and asks where in the telemetry pipeline it belongs. Every signal travels the same chain: a producer emits it, a delivery path carries it to a destination, and a consumer reacts to it. Sort the work by that chain and the answer falls out. Generating the signal is the logging job: pick the log sources that answer the threats you care about (CloudTrail for who-did-what, VPC Flow Logs for what-talked-to-what, Route 53 Resolver query logs for where-they-tried-to-connect) and the finding services that read them (GuardDuty, Macie, Security Hub, Detective, AWS Config). Acting on the signal is the monitoring-and-alerting job: turn a finding or a log pattern into a notification or an automated response. Fixing the pipeline is the troubleshooting job: when a log or finding never appears, walk the same chain to find the broken link. The classic trap is reaching for a service by its logo instead of its job; two AWS services never do the same job, so name the job first and the service follows.
The domain unfolds in three steps: log it, alert on it, then troubleshoot the chain
Read this page as a map, then follow the three subtopics in order. Logging Solutions covers generating the signal: which sources to capture, where to centralize them (a dedicated logging account the workloads cannot reach), how to protect the store so the record is tamper-evident (CloudTrail log file integrity validation, S3 Object Lock), and which tool analyzes the data (CloudWatch Logs Insights, Athena, OpenSearch, Security Lake). Monitoring & Alerting covers acting on the signal: which detection service does which job, and the EventBridge fan-out pattern that turns a finding into an SNS notification or a Lambda auto-remediation. Troubleshooting Detection covers fixing the pipeline: when a log or finding is missing, separate the producer, the delivery path, and the consumer to name the failing link before you change anything. Logging builds the pipeline, alerting consumes it, and troubleshooting repairs it.
When two answers both work, prefer aggregate centrally through a delegated administrator and alert once at EventBridge
Across all three subtopics the exam rewards the same instinct: centralize, and build the wiring once. For multi-account telemetry, the right pattern is a delegated administrator in a dedicated security or audit account, not the Organizations management account; GuardDuty, Macie, Security Hub, Detective, and AWS Config all follow this model, and an organization trail centralizes CloudTrail to one logging account the members can write to but not read or delete. For alerting, findings do not page anyone on their own: every detection service emits to the default EventBridge bus, so one rule that filters on source and severity feeds SNS, Lambda, or Step Functions, rather than wiring each service to a notification target separately. The more centralized, less per-service answer is usually the exam-correct one because it contains blast radius and removes drift.
The detection pipeline: which job owns which signal (and where each is covered)
| Job in the pipeline | Decides | Key AWS services | Drill into |
|---|---|---|---|
| Generate the signal | What telemetry to capture, where to centralize and protect it | CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, Security Lake, Athena | Logging Solutions |
| Act on the signal | Which service finds the threat, and how a finding becomes an alert or response | GuardDuty, Macie, Security Hub, Detective, AWS Config, EventBridge, SNS | Monitoring & Alerting |
| Fix the pipeline | Why a log or finding is missing, and which link in the chain broke | IAM roles, KMS key policies, S3 bucket policies, service-linked roles, metric filters | Troubleshooting Detection |