SCS-C02 Security Logging and Monitoring Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create an AWS CloudTrail trail in each account and aggregate logs to a central S3 bucket.

  Why it's wrong here

  Setting up individual CloudTrail trails per account and shipping logs to a central S3 bucket only aggregates raw audit logs; it doesn't automatically inspect them for root user activity. To alert, you'd need to build separate infrastructure such as CloudWatch Logs metric filters, Athena queries, or a Lambda function to parse the logs and trigger notifications in each account. This approach requires manual setup and maintenance in every account, introducing operational overhead and configuration drift, whereas the requirement calls for centralized detection and alerting.

• ✗

  Use IAM Access Analyzer to find resources shared with external entities.

  Why it's wrong here

  IAM Access Analyzer is designed to identify resources such as S3 buckets, KMS keys, or IAM roles that are shared with external principals via resource-based policies. It generates findings for unwanted external access, but it does not monitor or assess API-call behavior, authentication events, or the use of root user credentials. Root activity is an identity-centric event recorded in CloudTrail, not a resource-external-sharing condition, so this service cannot satisfy the detection requirement.

• ✗

  Use AWS Config rules to detect root user usage in each account.

  Why it's wrong here

  AWS Config rules are per-account and focus on evaluating the compliance of resource configurations, not on analyzing CloudTrail API activity to detect unauthorized root usage. While you could write a custom AWS Config rule backed by a Lambda function to query recent root logins, you'd have to deploy it in every account and it would not provide a consolidated view or native alerting across the organization. Config also lacks the anomaly-detection and threat-intelligence capabilities that GuardDuty uses to flag suspicious root activity.

• ✓

  Enable Amazon GuardDuty in the management account and use the delegated administrator feature.

  Why this is correct

  Enabling GuardDuty in the management account and designating a delegated administrator lets one account manage GuardDuty for all member accounts in the organization, aggregating findings centrally. GuardDuty uses integrated threat intelligence and anomaly detection to analyze CloudTrail management events, VPC flow logs, and DNS logs, generating a specific finding type when root user credentials are used anomalously, such as 'UnauthorizedAccess:IAMUser/RootCredentialUsage'. This provides cross-account visibility and built-in detection without needing to build custom log-analysis pipelines in each account.

Go deeper

Related to this question