SAP-C02 Practice Question 31: Org Wide Threat Detection
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 4 · question 1 of 10
A company runs 300 accounts in AWS Organizations across four AWS Regions, and its platform team creates new accounts most weeks. A central security operations team, which works from a dedicated security tooling account, must see Amazon GuardDuty findings for every account in one console, must be able to change detector settings for member accounts itself, and must have coverage begin on any new account with nobody remembering to act.
Company policy is that day-to-day security operations must not be performed from the organization's management account, and the platform team does not want to maintain a per-account stack that a local administrator could delete.
What should the solutions architect do?
Show answer and explanation
Answer:
The management account can designate any account in the organization as the delegated GuardDuty administrator, and that administrator can then enable and manage GuardDuty for every member account and view all of their findings, which keeps daily security work out of the management account, as AWS itself recommends. Two details matter here. GuardDuty is a Regional service, so the same delegated administrator must be designated in each of the four Regions. And the auto-enable preference must be set to cover all accounts, not just new ones: with the setting scoped to new accounts only, the 300 accounts that already exist are not enabled, and the "new" setting also behaves unexpectedly for opt-in Regions. One delegated administrator supports up to 50,000 members, so 300 is far inside the limit.
Option A produces the visibility but at 300 accounts' worth of manual enablement and 300 EventBridge rules to build and re-create for every new account, and it never establishes an administrator/member relationship, so the security team still cannot change a member's detector configuration.
Option B misreads how GuardDuty works. Enabling it in the management account protects that account only; it does not inspect member account activity.
Option D is a reasonable aggregation pattern but it is the per-account stack the platform team ruled out; a local administrator can delete the stack instance, drift has to be monitored, and the StackSet must run in four Regions for every new account. It also solves finding aggregation without giving the security team central control of member detector settings.
Reference: Managing GuardDuty accounts with AWS Organizations