A city wants continuous detection of anomalous API activity and potentially compromised instances across accounts. Which service should the architect enable as the intelligent threat-detection control?
Select an answer to reveal the explanation.
Short Explanation
CloudTrail is the security camera footage; GuardDuty is the analyst who watches it and raises a hand. Turn on GuardDuty for managed findings about odd API use and sketchy instance behavior. Inventory reports and Snowball orders are not your threat-detection brain.
Full Explanation
For continuous detection of anomalous API activity and potentially compromised instances across accounts, enable Amazon GuardDuty as the managed threat-detection control. GuardDuty analyzes CloudTrail management events, VPC Flow Logs, and DNS logs (among other signals) to produce findings about reconnaissance, instance compromise indicators, and suspicious API behavior—giving the city a managed detector rather than raw log piles alone.
Treating Amazon CloudTrail alone as the complete threat detector fails because CloudTrail is an audit record; without a findings engine, staff must manually notice anomalies across high-volume events. Using Amazon S3 Inventory reports as the primary indicator of compromised EC2 instances fails conceptually: inventory describes object storage contents/metadata, not instance threat behavior. Ordering AWS Snowball Edge devices as the mechanism to detect unusual API calls fails because physical data-transfer appliances are unrelated to continuous API anomaly detection.
Exam caveat: GuardDuty findings require response playbooks and often organization-level enablement; a detector that nobody triages does not reduce risk. Operational check: enable GuardDuty (preferably via delegated admin across accounts), confirm log sources are present, route findings to Security Hub or ticketing, and run a controlled simulated finding or use sample findings to verify on-call notification paths for municipal SOC staff.