A county wants to prevent anyone—including account administrators—from disabling Amazon GuardDuty in member accounts. Which control achieves that preventive goal?
Select an answer to reveal the explanation.
Short Explanation
IAM in a member account is like house rules the homeowner can rewrite. An SCP is the city ordinance that still applies even to the mayor of that account—so GuardDuty stays on. Stickers and honor-system IAM do not beat an administrator’s own policy changes.
Full Explanation
To prevent anyone—including member-account administrators—from disabling Amazon GuardDuty, use an AWS Organizations Service Control Policy that denies GuardDuty disable and delete APIs in member accounts. SCPs define the maximum permissions for IAM principals in those accounts and cannot be removed by the member account's own administrators. That is the preventive control that survives local IAM policy edits—the city ordinance that still binds the department mayor.
An IAM inline policy on one admin user that politely asks them not to disable GuardDuty can be detached by any peer admin with iam permissions. A sticky note listing GuardDuty account IDs is not an authorization control. Turning off CloudTrail so administrators cannot be blamed removes detective capability and does nothing to keep GuardDuty enabled.
Exam caveat: enable GuardDuty organization-wide from a delegated administrator account when possible; SCPs should deny guardduty:DeleteDetector, DisassociateFromMasterAccount/DisassociateFromAdministratorAccount, and related stop/disable actions carefully so legitimate admin of findings still works. SCPs do not apply to the management account like members. Operational check: from a member admin role, attempt to delete or disable the detector and expect AccessDenied; confirm findings still flow to the security tooling account; review SCP attachment on the correct OU.