You run an AWS Organization with dozens of member accounts. Design CloudTrail so that an attacker who obtains administrator access inside one member account cannot erase the record of what they did there.

## Frame it as two separate properties The question is not "how do I set up CloudTrail". It is: given that an attacker has full administrative power *inside one account*, what evidence still survives? Two things must be true independently, and candidates who conflate them design something that fails. **Property one: the attacker cannot stop the recording.** If the trail is a resource in the compromised account, an administrator there calls `StopLogging` or `DeleteTrail` and the story ends. Per-account trails owned by the account they audit are self-defeating by construction. **Property two: the attacker cannot reach what was already recorded.** Even a trail they cannot stop is useless if it delivers into a bucket they can empty. ## Property one — the organization trail An organization trail is created in the organization's management account, or in an account registered as CloudTrail's delegated administrator (`aws cloudtrail register-organization-delegated-admin`). Created with `--is-organization-trail`, it logs events for **every** member account in the organization, including accounts created after the trail existed — which matters more than it sounds, because the most common gap in a hand-rolled scheme is the account someone stood up last month that nobody enrolled. Crucially, the trail is owned by the management or delegated administrator account. Member-account principals can see it, but they cannot disable, modify or delete it. Local administrator power does not reach it, because the resource is not theirs. Make it `--is-multi-region-trail` as well. A regional trail is an invitation to do the work in a region nobody logs; multi-region also means regions that AWS enables later are covered automatically. ```bash aws cloudtrail create-trail \ --name org-audit-trail \ --s3-bucket-name central-log-archive-111122223333 \ --is-organization-trail \ --is-multi-region-trail \ --enable-log-file-validation ``` ## Property two — a destination outside the blast radius Deliver into an S3 bucket in a **dedicated log-archive account** that exists for nothing else: no workloads, no developer access, ideally no interactive human access at all outside a break-glass path. The bucket policy grants CloudTrail the delivery permission and grants read to the security team's role. Nobody in the workload accounts has any principal there, so compromising a workload account gives no path to delete the evidence — you have moved the destruction of evidence from "one compromised administrator" to "two independently compromised accounts". Harden the destination further: keep versioning on so an overwrite does not destroy the prior object, apply a retention control on the bucket so objects cannot be deleted before the retention period even by that account's administrators, and encrypt with a key whose policy is also managed there. Note the deliberate tension — those controls make the logs genuinely hard to erase, and equally hard to erase by mistake, so set the retention window with the legal and compliance requirement in hand rather than guessing high. ## Making the attempt visible Design for the attempt, not only the success. `StopLogging`, `DeleteTrail`, `PutEventSelectors`, `UpdateTrail` and `DeleteBucketPolicy` are all management events, so they are recorded by the trail itself. Alarm on them. A denied attempt is one of the highest-signal alerts you will ever have: legitimate operations rarely try to stop the audit trail, so the false-positive rate is near zero. Organization-level guardrails complement this — a policy applied across the organization that denies the CloudTrail control-plane actions in member accounts turns "they cannot touch this trail" into "they cannot create a confusing parallel one or tamper with local logging either". Keep in mind that such guardrails do not constrain the management account itself, which is precisely why the management account must be treated as tier-zero: no workloads, minimal principals, hardware MFA on root. ## What still is not covered, and say so - Data events remain opt-in. An organization trail with only management events will show the attacker changing a bucket policy and not which objects they read. Decide per data class where object-level logging is worth its cost. - Delivery is measured in minutes, so the trail is forensic evidence, not a real-time trip wire; detection is a separate layer fed by it. - Integrity validation detects tampering rather than preventing it — prevention is the cross-account destination plus retention. - Compromise of the management or delegated administrator account defeats the whole design. That account is the trust root, so its own protection is the ceiling on everything above. ## The judgment being tested The strong answer is structural: move the control of logging and the storage of logs into a different trust domain from the workloads being logged, so that no single account compromise both generates and destroys the evidence. Everything else — validation, retention, alarms — hardens that structure. A candidate who lists features without naming the separation-of-trust-domains idea has described a configuration, not a design.