SCS-C02 Threat Detection and Incident Response 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.

• ✗

  Enable GuardDuty in each member account and configure cross-account IAM roles to aggregate findings in the management account.

  Why it's wrong here

  This approach requires GuardDuty to be enabled independently in every account, so findings are generated only in the local account's console and API. Aggregating them into the management account would demand custom automation—such as cross-account IAM roles and a Lambda function that calls ListFindings/GetFindings against every member account—because GuardDuty has no native mechanism to push findings to a central account through IAM roles. It also foregoes the delegated administrator model, which automatically aggregates findings at the API level without custom infrastructure.

• ✗

  Enable GuardDuty only in the management account and share findings via CloudWatch Logs cross-account subscription.

  Why it's wrong here

  Enabling GuardDuty solely in the management account gives no visibility into member accounts because GuardDuty can analyze only data that originates in the account where it is enabled (e.g., VPC Flow Logs, DNS logs, and CloudTrail events from that account); member accounts would produce zero findings. Even if you attempted a CloudWatch Logs cross-account subscription, GuardDuty findings are not automatically logged to CloudWatch Logs—they are stored as structured findings in GuardDuty, which can optionally be exported to S3 or forwarded to CloudWatch Events. The intended path for centralization is to use a delegated administrator that enables GuardDuty across all accounts, thus making member findings available to the admin account.

• ✓

  Designate a delegated administrator account in Organizations, then enable GuardDuty in that account. GuardDuty will automatically aggregate findings from member accounts.

  Why this is correct

  This is the recommended multi-account design. By designating a delegated administrator through AWS Organizations, the admin account can enable GuardDuty across every member account with a single action and receives a consolidated view of all findings in the GuardDuty console and via the API. The delegated administrator also gains centralized control to manage member accounts, apply trusted IP lists, configure threat list filters, and create suppression rules for the entire organization. This integration is natively built into GuardDuty, so no custom IAM roles or log-forwarding pipelines are required to aggregate findings.

• ✗

  Enable GuardDuty in the management account and use CloudWatch cross-account dashboard to view findings from member accounts.

  Why it's wrong here

  This approach is fundamentally flawed because enabling GuardDuty in the management account does not monitor member accounts, so a CloudWatch cross-account dashboard would have no member-account findings to display. GuardDuty findings are not directly streamed to CloudWatch Logs; they must be explicitly exported via S3 or delivered through CloudWatch Events, and even then only the management account's own findings would exist unless GuardDuty is enabled in every member account. The proper way to aggregate findings across accounts is GuardDuty's delegated administrator feature with AWS Organizations, which collects member findings without the need for a CloudWatch dashboard.

Go deeper

Related to this question