Member accounts must be prevented from leaving the organization or disabling central security services. Which governance control should the architect apply?
Select an answer to reveal the explanation.
Short Explanation
SCPs are the charter amendments member cities can’t quietly repeal. Deny LeaveOrganization and deny turning off the mandated security stack. Handshakes, deletable local IAM, or blog posts aren’t enforceable governance.
Full Explanation
Preventing member accounts from leaving the organization or disabling central security services requires Organizations service control policies that deny those actions at the account permission ceiling. SCPs applied to OUs enforce that members may not leave and may not turn off mandated GuardDuty, CloudTrail, or Config capabilities regardless of local AdministratorAccess. Verbal agreements and optional blogs cannot replace enforceable preventive controls for a municipal organization that must keep security telemetry on.
Verbal agreements with account owners and no enforceable policy fail the first time a team wants to opt out during an incident or budget squeeze. IAM policies only in member accounts that administrators can delete at will are not organization-level guardrails and can be removed by the very principals they constrain. Public blog posts describing preferred settings without enforcing them create awareness without control and will not satisfy auditors asking what technically prevents disablement.
Exam caveat: SCPs deny capabilities across member accounts and cannot be removed by local admins; use them for leave-organization and disable-security prevents on SAP-C02 multi-account designs. Operational check: attach deny-leave and deny-disable-security SCPs to workload OUs, attempt LeaveOrganization and detector or trail deletion from a member admin role, confirm AccessDenied, and monitor Config for residual drift.