Logging, Monitoring, and Incident Response
This domain tests whether you can detect, investigate, and respond to cloud incidents using the right telemetry and preserved evidence.
Core rules
- Enable control-plane audit logs in all regions (CloudTrail, Azure Activity Log, GCP Audit Logs) and data-plane logs where required. Many data events are not on by default.
- Centralize logs in a restricted account, synchronize time, protect integrity, and set retention aligned to legal and incident-response needs.
- Monitor identity, key use, network flows, and configuration drift; alert on high-signal events such as root use or key deletion.
- Incident response in cloud: preserve evidence with snapshots and log exports, isolate with security groups, rotate credentials, and document chain of custody.
Worked example
An access key may be compromised. The responder checks CloudTrail for the key's recent API calls, reviews GuardDuty findings, and inspects VPC flow logs for unusual destinations. They disable the key, attach a restrictive security group to affected instances, snapshot disks, and preserve logs. Reasoning: containment must not destroy evidence; disabling the key stops abuse while snapshots and logs support scope analysis.
Traps
- Assuming default logging is enough.
- Forgetting data-plane and SaaS audit logs.
- Deleting or shortening logs during response.
- Having no cloud-specific incident-response runbook or evidence procedure.