SCS-C02 Threat Detection and Incident Response Practice Question

A security engineer is configuring Amazon GuardDuty in a multi-account environment using AWS Organizations. The engineer wants to designate a delegated administrator account to manage GuardDuty for all member accounts. Which AWS service must be used to enable GuardDuty for all accounts?

⚠ Common exam trap

Many exam-takers confuse AWS Organizations as merely an organizational tool and think they need a separate service like CloudFormation StackSets or Control Tower to enable GuardDuty across accounts, but GuardDuty natively integrates with Organizations for delegated administration and automatic enablement.

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

✓

AWS Organizations

AWS Organizations is the foundational service required to designate a delegated administrator for Amazon GuardDuty in a multi-account environment. GuardDuty integrates directly with Organizations to allow a management account to enable GuardDuty for all member accounts and delegate administration to a specified account, which then manages threat detection across the organization without needing additional services.

Answer analysis

Option-by-option breakdown

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

✗
AWS CloudFormation StackSets
Why it's wrong here
AWS CloudFormation StackSets can deploy the same CloudFormation template to multiple accounts, so in theory you could build a custom template that creates GuardDuty detectors and member associations in each target account. That approach is not GuardDuty's native multi-account solution, however, because StackSets require you to author and maintain all the resource logic yourself and they do not provide centralized delegated administration or automatic onboarding of new accounts. GuardDuty's built-in integration with AWS Organizations handles exactly that, which is why StackSets are not the primary service for multi-account GuardDuty.
✗
AWS Control Tower
Why it's wrong here
AWS Control Tower is a governance service that helps you establish a landing zone and apply preventive and detective guardrails across accounts, and it can be configured to deploy GuardDuty as part of that baseline. Control Tower is not required for GuardDuty, though, because GuardDuty can be enabled and managed using AWS Organizations alone, without any landing-zone orchestration. Thus Control Tower is an optional automation layer, not the service that GuardDuty actually integrates with for multi-account management.
✗
AWS Config
Why it's wrong here
AWS Config records resource configuration changes and evaluates those configurations against managed or custom rules; it can be used to detect whether GuardDuty is enabled or compliant, but it has no capability to create a GuardDuty detector or to link member accounts to an administrator. Enabling GuardDuty across an organization is an action taken by GuardDuty itself, not by Config, so Config is not the tool that enables the multi-account setup—it could only serve as a post-hoc compliance check.
✓
AWS Organizations
Why this is correct
AWS Organizations is the foundation for GuardDuty's multi-account management: when you designate a delegated administrator and enable GuardDuty for the organization, GuardDuty automatically provisions detectors in all current and future member accounts and centrally aggregates their findings. This native integration lets you onboard new accounts without manual invites and gives you unified visibility through the administrator account, making Organizations the correct answer.

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question