Domain 1 · Detection | Asterrr's Handbook

16% of the exam. Choosing what to watch, where the logs land, how findings become alerts, and why a monitoring pipeline goes quiet.

Domain 1 questions give you an account or an organization and ask how you would know something bad happened: which service detects it, which log proves it, where the evidence is stored, and who gets paged. A growing share of questions describe monitoring that already exists but stopped working, and ask for the one misconfiguration.

Task	What it's really asking	Pages
1.1 Monitoring and alerting	Which managed detector covers the threat, how findings are aggregated across accounts, and how they turn into alarms, notifications and dashboards	Threat detection, Security findings hub, Alerting and dashboards
1.2 Logging	Which log source answers the question, how to collect it org-wide into a separate account, and how to query or normalize it	Logging strategy, Log analysis
1.3 Troubleshooting	Missing logs, silent alarms, rules that never fire, agents that don't ship, and the permission or key policy behind each	Troubleshooting monitoring

What connects Domain 1 to the rest of the exam:

Detection feeds incident response: once a finding fires, the playbook lives in Automated response.
Log buckets and log groups are data too. Their encryption and immutability rules are in S3 data protection and KMS key management.
The account layout (security tooling account, log archive account) comes from Multi-account strategy.

Building your own detector

Options that write a Lambda function to parse CloudTrail for "suspicious" behaviour, or run an IDS on EC2 to catch crypto-mining, are rarely right. If a managed service already detects the threat (GuardDuty for threats, Macie for sensitive data, Inspector for vulnerabilities), the answer is to turn it on everywhere through a delegated administrator and route its findings.