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.

• ✓

  Designate a Delegated Administrator account for GuardDuty in AWS Organizations and enable GuardDuty for all accounts from that account.

  Why this is correct

  By designating a delegated administrator for GuardDuty in AWS Organizations, you centralize management and allow GuardDuty to automatically enable itself for all existing and future accounts. This creates a single detector per region in the delegated admin account with all member accounts linked underneath, so findings are aggregated without manual per-account setup. This is the native, supported pattern for scaling GuardDuty across an organization.

• ✗

  Use AWS CloudFormation StackSets to deploy a GuardDuty detector in each account.

  Why it's wrong here

  CloudFormation StackSets can deploy a GuardDuty detector template to every member account, but it does not integrate with GuardDuty's organization management model. It lacks the delegated-administrator relationship, so each account's detector operates independently with no automatic member-to-member configuration or centralized finding consolidation. Even with StackSets' automatic deployment to new accounts, this only creates raw resources; you would still have to manually wire up the member account relationships and aggregate findings, unlike GuardDuty's native delegated admin.

• ✗

  Enable AWS Security Hub in the management account and configure it to ingest GuardDuty findings from member accounts.

  Why it's wrong here

  Security Hub is a findings aggregation service, not an enablement service: it can ingest GuardDuty findings only after GuardDuty is already enabled in each account. Enabling Security Hub in the management account and configuring it to receive GuardDuty findings will not create detectors in member accounts, nor will it automatically enroll new organization accounts. This option reverses the dependency, because GuardDuty must be active and linked to the delegated administrator before Security Hub can centralize its findings.

• ✗

  Enable GuardDuty in each member account individually and configure cross-account access to a central S3 bucket.

  Why it's wrong here

  Manually enabling GuardDuty in each member account and configuring cross-account access to a central S3 bucket for findings export is possible but operationally brittle and not scalable. It requires per-account IAM roles, bucket policies, and detector configuration, and new organization accounts are not automatically protected. This approach only supports one-way finding delivery to S3; it does not centralize management, enable automated responses, or maintain the organization member relationship that GuardDuty's delegated administrator provides.

Go deeper

Related to this question