SCS-C03 opens with detection because you cannot respond to what you never noticed. Task 1.1 tests whether a candidate can analyze a workload's monitoring requirements and then design alerting that surfaces anomalous activity across an entire AWS account -- or, more realistically at specialty level, across an AWS Organization spanning dozens of accounts.
From Workload Analysis to Aggregated Events
Monitoring strategy starts with understanding what "normal" looks like for a given workload: expected API call volume, typical network flows, baseline resource utilization. Only against that baseline does anomalous behavior become visible. Resource health checks (load balancer target health, EC2 status checks, Route 53 health checks) catch availability problems, but security monitoring goes further, aggregating security-relevant events from many sources into a small number of places a human or automated system can actually watch. A single account generates far more signal than any person can review line by line, and an organization multiplies that by every member account -- so the design problem is really an aggregation and prioritization problem, not a "turn on more logging" problem.
The Core Detection Services
Four services do most of the heavy lifting for anomaly detection at the account/organization level. Amazon GuardDuty is a managed threat detection service that continuously analyzes CloudTrail management and data events, VPC Flow Logs, and DNS logs (without you having to enable those sources yourself) to surface findings like credential compromise, reconnaissance, or malware communication -- and it can be enabled organization-wide from a delegated administrator account so every member account is covered automatically. AWS Security Hub aggregates findings from GuardDuty, Macie, Inspector, and third-party tools into a single normalized view, applies security standards (like the AWS Foundational Security Best Practices standard) to score compliance, and can trigger automated response workflows. Amazon Macie focuses specifically on sensitive-data discovery in S3, using machine learning and pattern matching to find PII, credentials, and other sensitive content, and flags buckets that are unexpectedly public or unencrypted. Amazon Security Lake centralizes security data from AWS services, on-premises sources, and third-party tools into a purpose-built data lake using the Open Cybersecurity Schema Framework (OCSF), so that disparate log formats become queryable in one normalized shape -- this is the foundation the exam expects you to reach for when a scenario calls for long-term, cross-source security analytics rather than just real-time alerting.
Turning Signals into Action
Raw findings are not useful until they become metrics, alerts, and dashboards: CloudWatch metrics and alarms convert log patterns and service findings into actionable thresholds, and dashboards give a single-pane view across accounts. Beyond passive alerting, the exam expects familiarity with automations that perform regular assessments on their own -- AWS Config conformance packs bundle sets of Config rules (and remediation actions) that continuously evaluate resource configuration against a defined baseline, Security Hub can run its own scheduled checks, and Systems Manager State Manager enforces and reports on defined system state (patch level, agent configuration) across a fleet without a human triggering each check. The unifying theme across all of Task 1.1 is that at organization scale, monitoring has to be designed to work without someone constantly watching a screen -- alerts, dashboards, and automated conformance checks close that gap.
Key Mechanics
- Monitoring strategy starts with a workload baseline; anomaly detection is meaningless without knowing what "normal" looks like first.
- GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs automatically (no source enablement required) and can be enabled org-wide from a delegated administrator.
- Security Hub aggregates and normalizes findings from GuardDuty, Macie, Inspector, and third parties, and scores compliance against security standards.
- Macie is specifically for sensitive-data discovery and classification in S3.
- Security Lake centralizes security data across sources into OCSF format for long-term analytics -- the answer when a scenario needs cross-source correlation, not just real-time alerts.
- Config conformance packs and Systems Manager State Manager provide automated, recurring compliance assessment without manual triggering.
Exam Tip: If a scenario asks for continuous threat detection across CloudTrail, VPC Flow Logs, and DNS activity with no source configuration required, that's GuardDuty -- distinguish it from Security Hub, which aggregates findings rather than generating its own from those raw sources.
Exam Tip: "Normalizes security data from multiple sources into a queryable data lake using OCSF" is Security Lake's signature description on the exam -- don't confuse it with Security Hub's finding-aggregation role.
Exam Tip: A scenario mentioning recurring, automated assessment of resource configuration against a defined baseline (without a human running the check) points to Config conformance packs or Systems Manager State Manager, not a one-time manual audit.
Worked example: A security team managing a 40-account AWS Organization wants automatic detection of compromised credentials and reconnaissance activity across every account, without each account team having to individually enable data sources. They designate a delegated administrator account and enable GuardDuty at the organization level, which automatically applies to all member accounts; findings then flow into Security Hub in that same delegated administrator account, giving the team one normalized, prioritized view instead of 40 separate consoles to check.