A county IT board wants separate AWS accounts for parks, finance, and shared services, plus a guardrail so no account can disable CloudTrail. Which design best meets that requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of the county like three locked offices under one city hall roof, with a rule nobody can yank the security cameras. Organizations plus SCPs (and Control Tower when you want the landing-zone kit) put that rule above every account so CloudTrail stays on. One flat account with a pinky swear is not a guardrail.
Full Explanation
For a county that needs distinct AWS accounts for parks, finance, and shared services while guaranteeing CloudTrail cannot be turned off, AWS Organizations with Service Control Policies is the control plane that matches the requirement. Member accounts remain separately billed and permissioned, yet they sit under a single organization root where SCPs apply as permission guardrails that no account administrator can override from inside the member account. AWS Control Tower is appropriate when the board also wants a governed landing-zone baseline (logging account, baselines, and account factory), but the exam-critical mechanism that blocks "disable CloudTrail" is still the SCP deny on the relevant CloudTrail and related management actions. Think of Organizations as city hall and SCPs as ordinances that apply even to department mayors: parks and finance get their own buildings, but nobody is allowed to unplug the security cameras.
A single shared AWS account with AdministratorAccess IAM users fails the separation goal and the guardrail goal. Collocation means a finance principal can, by policy mistake or compromise, reach parks resources; local IAM cannot impose an unbreakable "CloudTrail must stay on" rule against administrators who can edit their own policies. Storing CloudTrail only in each account's local CloudWatch Logs group without an organization-level policy likewise fails: trails and log groups can be altered or deleted by privileged principals in that account, and there is no centralized immutable control. Granting departments long-lived IAM user access keys plus a verbal promise not to disable CloudTrail is governance theater—promises are not enforceable authorization, keys expand the credential blast radius, and nothing prevents DeleteTrail or StopLogging API calls.
Exam caveat: SCPs do not grant permissions; they only filter the maximum permissions available in member accounts. You still need identity policies (and typically a dedicated logging account with an organization trail) so CloudTrail can write. SCPs also do not apply to the management account the same way as to members—design logging and break-glass carefully. Operational check: after attaching the SCP, attempt StopLogging/DeleteTrail from a member admin role (in a nonprod proof account) and confirm AccessDenied; verify an organization trail delivers to a central log bucket with restricted delete rights and that CloudTrail events still appear for console and API activity across parks, finance, and shared services.