SCS-C02 Threat Detection and Incident Response Practice Question

An organization uses AWS Organizations and wants to centrally manage Amazon GuardDuty across multiple accounts. What is the correct architecture?

⚠ Common exam trap

Watch out — candidates often assume enabling GuardDuty in the master account automatically covers all member accounts (Option A), but in reality, GuardDuty requires explicit member account management or a delegated administrator setup, and the delegated administrator model is the recommended architecture for centralized management in Organizations.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Designate a delegated administrator account in Organizations and enable GuardDuty in that account.

AWS Organizations allows you to designate a delegated administrator account for Amazon GuardDuty, which can then centrally manage GuardDuty across all member accounts in the organization. This architecture simplifies enabling GuardDuty and managing findings without needing to configure each account individually, as the delegated administrator can enable GuardDuty for all accounts in the organization from a single point.

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 only in the master account; it will automatically monitor all member accounts.
Why it's wrong here
GuardDuty is a per-account, per-region service; enabling it only in the master account does not automatically enable it in member accounts. The master account must explicitly add member accounts and each member must accept the invitation, even then the detector must be enabled in each account and region. Without that, the master account sees no findings from its members.
✗
Use AWS CloudFormation StackSets to deploy GuardDuty in all accounts and regions.
Why it's wrong here
AWS CloudFormation StackSets can deploy the GuardDuty detector resource to all accounts and regions, but that only creates detectors; it does not configure the centralized delegated administrator relationship, membership, or cross-account findings aggregation that Organizations delegated admin provides. StackSets is a deployment mechanism, not the central management architecture, so it does not meet the requirement for central management.
✓
Designate a delegated administrator account in Organizations and enable GuardDuty in that account.
Why this is correct
The correct approach is to designate a delegated administrator account in AWS Organizations for GuardDuty. This delegated admin can enable GuardDuty for all member accounts, manage their detectors, and view aggregated findings centrally without needing per-account invitations. It is the only method that provides a single admin control plane over multi-account GuardDuty coverage and findings.
✗
Enable GuardDuty in each region separately and use cross-region aggregation.
Why it's wrong here
GuardDuty is a regional service; enabling it separately in each region handles multiple regions within a single account. Cross-region aggregation only consolidates findings for the same account across all regions, not across different accounts. Multi-account management still requires either Organizations delegated admin or the older method of individual member invitations, so this option fails to provide central management across accounts.

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question