Detection is the first SCS-C03 domain because AWS wants to know whether you can build a signal path that actually helps responders make decisions. The exam is usually not asking whether you recognize GuardDuty, CloudTrail, Security Hub, or Security Lake by name. It is asking whether the security telemetry is complete, centralized, analyzable, and actionable.
What AWS is explicitly testing
As of May 11, 2026, the current AWS Documentation exam guide splits this domain into three tasks:
- Task 1.1: design and implement monitoring and alerting solutions for an AWS account or organization
- Task 1.2: design and implement logging solutions
- Task 1.3: troubleshoot security monitoring, logging, and alerting solutions
That split is useful on the exam. If the problem is about which findings, metrics, alerts, or automations should exist, it is a monitoring problem. If it is about what evidence should be collected and where it should land, it is a logging problem. If the prompt says the telemetry is missing, delayed, or incomplete, it is a troubleshooting problem.
Current weight in the exam guide
AWS currently weights this domain at 16% of scored content.
Work this domain in order
Start with 1.1 Monitoring and Alerting Solutions to separate findings, metrics, dashboards, health signals, and automated assessment patterns.
Then move to 1.2 Logging Solutions to lock down source selection, centralized ingestion, Security Lake, log analysis, and correlation.
Finish with 1.3 Troubleshooting Monitoring and Logging because many exam questions are really about why logs or alerts did not appear where expected.
Fast routing inside this chapter
| If the scenario is really about… |
Go first to… |
| GuardDuty, Security Hub, Macie, dashboards, anomaly detection, delegated admin, alerting, or recurring assessments |
1.1 Monitoring and Alerting Solutions |
| CloudTrail, VPC Flow Logs, Route 53 Resolver logs, Security Lake, centralized log accounts, parsing, Athena, or log storage design |
1.2 Logging Solutions |
| missing logs, broken agents, misconfigured destinations, no findings, no alerts, or “why is the signal path incomplete?” |
1.3 Troubleshooting Monitoring and Logging |
What strong SCS-C03 answers usually do
- collect the right evidence before adding more tooling
- centralize findings and logs at organization scale instead of leaving detection account-by-account
- separate finding generation, log collection, and downstream alerting
- prefer managed aggregation and normalization patterns when the requirement is multi-account visibility
- verify permissions, destinations, retention, and parsing paths before blaming the security service itself
Common detection traps
- enabling a detector without designing how findings are aggregated and acted on
- collecting every log source without matching it to a threat, control, or retention need
- treating Security Hub as raw log storage
- using CloudTrail alone when the question really needs DNS, network, application, or data-event visibility
- troubleshooting “missing alerts” without checking whether the logs or findings ever existed upstream
Best review order late in prep
Revisit this chapter when:
- you mix up findings, metrics, logs, and dashboards
- organization-level delegated administration still feels fuzzy
- you choose the wrong log source for a network or data exfiltration scenario
- troubleshooting questions make you jump straight to the wrong service
In this section
-
SCS-C03 Monitoring and Alerting Solutions Guide
Study SCS-C03 monitoring and alerting for GuardDuty, Security Hub, Macie, dashboards, anomaly detection, and assessment automation.
-
SCS-C03 Logging Solutions Guide
Study SCS-C03 logging solutions for CloudTrail, Security Lake, flow logs, centralized storage, analysis, and correlation.
-
SCS-C03 Troubleshooting Monitoring and Logging Guide
Study SCS-C03 troubleshooting for missing logs, broken alerting, permissions gaps, and misconfigured monitoring pipelines.