SCS-C03 · D1 · 16%

Detection

Design organization-scale monitoring, capture the right telemetry, and diagnose gaps between signals, findings, alerts, and responders.

Provider facts checked 2026-08-03

Objective coverage

Objective 1.1 · high

Design and implement monitoring and alerting

Design monitoring and alerting for AWS accounts and organizations, including ownership, aggregation, prioritization, and response routing.

Lesson
d1-lesson
Practice pool
d1-questions
Application
scs-l01, scs-l02
Objective 1.2 · high

Implement logging

Select, protect, centralize, normalize, and retain security-relevant logs for detection, investigation, and assurance.

Lesson
d1-lesson
Practice pool
d1-questions
Application
scs-l01
Objective 1.3 · normal

Troubleshoot monitoring, logging, and alerting

Trace missing or noisy signals across configuration, permissions, delivery, aggregation, suppression, and notification layers.

Lesson
d1-lesson
Practice pool
d1-questions
Application
scs-l02

Decision frame

Detection begins with a decision a responder must make, not with a service to enable. Work backward from the decision to the evidence, collection boundary, delivery path, prioritization rule, accountable owner, and proof that the path works. A source that writes records but never reaches a responder is logging, not a complete detection capability. A finding that reaches a queue but has no owner is delivery, not response.

Trace every important behavior through this chain:

activity → authoritative record → protected destination → normalization or finding → prioritization → routed action → accountable responder → validation

At organization scale, add account enrollment, Regions, delegated administration, resource and KMS policies, retry behavior, dead-letter handling, retention, immutability, and the ability to investigate across accounts without giving workload administrators control over evidence.

Objective map

ObjectiveWhat you must decideEvidence of a sound design
1.1 Design and implement monitoring and alertingWhich behaviors matter, how they are detected, who owns them, and what response time is requiredA known event becomes one correctly enriched, prioritized, and owned alert
1.2 Implement loggingWhich records are authoritative, where they are collected, how they are protected, and how long they remain usefulCoverage and delivery tests plus a tamper-resistant central record
1.3 Troubleshoot monitoring, logging, and alertingWhich layer lost, delayed, duplicated, suppressed, or misrouted the signalA layer-by-layer trace that isolates the failure without changing unrelated controls

Build the telemetry model

Separate raw evidence, derived signals, and coordination records. AWS CloudTrail records API activity; data events and Insights events answer different questions from management events. AWS Config records resource configuration and change relationships. VPC Flow Logs, Route 53 Resolver query logs, load-balancer logs, AWS WAF logs, and workload logs illuminate different portions of a request path. Amazon GuardDuty produces managed threat findings. AWS Security Hub CSPM aggregates and normalizes supported findings, while Amazon Security Lake can centralize supported security data in the Open Cybersecurity Schema Framework. None is a universal replacement for the others.

For each source, document scope, Region behavior, event selectors, delivery destination, encryption owner, resource policy, failure metric, retention, query method, and expected delay. Organization-wide collection usually belongs in a dedicated log archive or security account with delegated administration. Workload teams may need query access, but they should not be able to stop collection or rewrite retained evidence.

Choose detection logic from the behavior and response requirement. Use a metric alarm when a numeric threshold or absence of a metric is meaningful. Use EventBridge when a structured event should route into a workflow. Use managed findings when AWS already supplies the relevant analysis. Use query or analytics services when correlation across a larger evidence set is required. Preserve the original record or a durable pointer so responders can test the finding rather than trusting a transformed notification.

Decision patterns

RequirementPreferDo not confuse it with
Record authoritative API activityCloudTrail with appropriate selectors and organization coverageA CloudWatch metric derived from only some events
Detect resource configuration driftAWS Config rules, conformance packs, or approved custom evaluationA point-in-time inventory with no change history
Aggregate supported security findingsSecurity Hub CSPM with delegated administration and routingRaw log storage or a SIEM replacement by itself
Detect managed threat patternsGuardDuty with organization enrollment and finding exportProof that every underlying log source is complete
Retain broad normalized security dataSecurity Lake with governed subscribers and lifecycleAn alerting workflow with human ownership
Route a structured findingEventBridge to a durable, observable targetA best-effort notification with no retry or dead-letter path

Treat suppression as code or governed configuration. A useful suppression rule names the noisy condition, its owner, expiry, compensating visibility, and validation method. Broadly lowering severity or discarding events hides operational debt. Aggregate duplicates only when the correlation key is stable and the underlying evidence remains available.

Troubleshooting sequence

When an alert is missing, start at the source and move forward. Confirm the activity occurred in the expected account and Region. Confirm collection covered that event type. Check service permissions, destination resource policy, KMS key policy, network path where relevant, delivery health, parser or normalization, rule conditions, suppression, target permissions, retries, and the responder's queue. When an alert is noisy, work in the reverse direction: identify the decision responders cannot make, find the rule producing low-value matches, then improve context, aggregation, threshold, or scope without erasing the evidence.

Check time semantics. Event time, ingestion time, processing time, and notification time are different. Cross-account correlation can fail when clocks, identifiers, or Region assumptions are inconsistent. A successful API response from a configuration action does not prove that a later event was delivered, parsed, matched, and handled.

Scenario drill

A company enables an organization trail and GuardDuty in its security account. A member account creates an access key and uses it from an unusual network. CloudTrail contains the API calls, but the security operations queue receives nothing.

  1. Identify the expected source record and whether the correct CloudTrail event selector and Region cover it.
  2. Determine whether the detection depends on a GuardDuty finding, a custom EventBridge rule, or both.
  3. Trace organization enrollment, delegated administrator status, finding aggregation, EventBridge pattern, target policy, retry metrics, and dead-letter records.
  4. Preserve the original event and finding IDs while testing the route with a harmless known event.
  5. Repair only the failed layer, replay or regenerate the test, and record end-to-end delivery time and ownership.

The strongest answer diagnoses the pipeline before replacing services or widening permissions.

Common traps

  • Enabling every source without retention, query ownership, or cost controls.
  • Treating Security Hub as the origin of every finding instead of an aggregation layer.
  • Granting the workload account permission to alter the central evidence store.
  • Monitoring only the home Region when the service or attacker activity can occur elsewhere.
  • Sending directly to an ephemeral target without retry, failure metrics, or a dead-letter path.
  • Assuming a successful notification proves that a person or automation completed the response.
  • Suppressing a noisy rule permanently without an owner, expiry, and compensating detection.

Self-check

  1. For one suspicious API call, name the authoritative record, aggregation path, responder, and validation event.
  2. Explain how a KMS key policy can break an otherwise correct log-delivery configuration.
  3. Distinguish a raw record, metric, finding, alert, and incident.
  4. Describe how you would prove all required accounts and Regions are enrolled.
  5. Defend one cost-control decision without losing the evidence needed for investigation.

Primary references