DOP-C02 Practice Question 10: Organization Trail Log Integrity

An organization trail is created once in the management account (or by a delegated administrator) and automatically logs events for every member account, including accounts joined later. Member account administrators see the trail but cannot modify or delete it, it is read-only from their side, which is what the last constraint requires. Log file integrity validation is the piece that supplies the cryptographic proof: CloudTrail computes a SHA-256 hash of each delivered log file and writes hourly *digest files*, each signed with a private key whose chain links to the previous hour's digest. aws cloudtrail validate-logs walks that chain and reports any log file that was altered or deleted, and any gap in the digest chain itself. No other option produces a verifiable assertion of that kind.

Option A gets coverage but not the guarantee. Per-account trails deployed by a StackSet are owned by the member accounts, so a local administrator can stop or reconfigure one, and the StackSet would have to be re-run or auto-deployed for each new account. Macie discovers sensitive data in S3; it does not attest to file integrity.

Option B has the right trail but the wrong integrity control. KMS encryption protects confidentiality and Versioning preserves prior object versions, but neither produces a signed hash you can present to an auditor, and a principal with sufficient S3 permissions can still delete versions. The stem asks specifically for cryptographic proof, which is CloudTrail's integrity validation feature.

Option D collects the wrong data. AWS Config records resource configuration state and compliance, not the API-call management events the auditor asked for. Object Lock in compliance mode does make the delivery bucket tamper-resistant, but it is a retention control on stored objects, not a means of validating that a given log file matches what CloudTrail originally emitted.

Reference: Validating CloudTrail log file integrity