skip to content

An auditor asks you to prove that the AWS CloudTrail logs you handed over have not been altered and that no entries were removed. What does CloudTrail's log file integrity validation give you, and what does it not prove?

level: middleimportance: nice to knowfreq 28%

answer

  1. hourly digest, not per event
  2. hashes chained to the previous digest
  3. signed by AWS, not by you
  4. detects tampering, does not prevent it
  5. says nothing about events never captured

basics

~20 s

With log file integrity validation on, CloudTrail delivers hourly digest files that hash each delivered log file and chain to the previous digest, signed by AWS. Validation detects modified, deleted or inserted files — it does not prove every API call was logged.

solid answer

~50 s

Enabling log file integrity validation makes CloudTrail write a **digest file** every hour alongside the logs. Each digest lists the log files delivered in that hour with their hashes, references the previous hour's digest, and is signed by AWS with a key whose public half you can verify against. That chaining is what turns it from a checksum into tamper *evidence*: altering a log file breaks its hash, deleting one breaks the digest that references it, and deleting a digest breaks the next digest's back-reference. You verify with `aws cloudtrail validate-logs --trail-arn ... --start-time ...`. What it does **not** prove is completeness of the source: it says nothing about events CloudTrail never generated — data events you never enabled, or a period after someone called `StopLogging`. It attests to the chain, not to the world.

code

bash · 4 lines
bash
aws cloudtrail update-trail --name org-audit-trail --enable-log-file-validation
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:111122223333:trail/org-audit-trail \
  --start-time 2026-08-01T00:00:00Z

go deeper

for a junior

Know that CloudTrail can be switched into a mode where it writes signed digest files next to the logs, and that a CLI command uses them to check the logs were not altered.

for a middle

Explain the hourly digest: per-file hashes, the reference to the previous digest that forms a chain, and the AWS-held signing key — then name validate-logs as the verification step.

for a senior

Draw the boundary an auditor cares about: integrity is not completeness, detection is not prevention, and the chain simply ends if someone calls StopLogging. Pair it with cross-account delivery and alarms on the trail's own control-plane calls.

for a principal

Position it as one control in an evidence chain of custody: decide what your compliance obligations actually require you to attest to, who verifies the chain independently of the team that operates it, and what retention and separation of duties make the attestation meaningful rather than ceremonial.

## The question behind the question An auditor handed a folder of JSON is entitled to ask why they should believe it. The logs live in an S3 bucket you control; anyone with write access could edit a line or delete an inconvenient hour. Log file integrity validation exists to make that tampering detectable by someone who does not trust you. ## The mechanism You turn it on per trail (`--enable-log-file-validation` on `create-trail` or `update-trail`). From then on, CloudTrail delivers, every hour, a **digest file** into the same bucket under a separate `CloudTrail-Digest` prefix. A digest contains: - the list of log files delivered during that hour, each with its hash, - the S3 location and the hash of the **previous** digest file, - a signature over the digest, produced by AWS with a private key held by AWS; the corresponding public key is retrievable through the CloudTrail API. Those three parts do different jobs. The per-file hashes catch edits inside a file. The list of files catches a file being deleted outright — the digest still names a file that is no longer there. The back-reference to the previous digest catches an attempt to delete or replace a whole hour of digests, because the following digest no longer resolves. And the signature stops you from simply regenerating a consistent set of digests yourself, since you cannot produce AWS's signature. The result is a hash chain anchored by a key you do not hold. That is the property an auditor is actually asking about. ## Validating ```bash aws cloudtrail update-trail --name org-audit-trail --enable-log-file-validation aws cloudtrail validate-logs \ --trail-arn arn:aws:cloudtrail:us-east-1:111122223333:trail/org-audit-trail \ --start-time 2026-08-01T00:00:00Z ``` The command walks the digest chain over the window, recovers the log files each digest references, recomputes hashes and reports files that are modified, missing, or unsigned, plus digests that are missing or out of order. It only covers the period after validation was enabled — turning it on today gives you nothing about last month. ## The limits, stated plainly This is where candidates either sound rigorous or sound like they read a feature list. **It proves nothing about completeness of capture.** The chain attests to what CloudTrail delivered. If S3 data events were never enabled, every object read is absent and the validation still passes cleanly, because nothing was tampered with — those events simply never existed. A green validation over an incomplete configuration is the most misleading artifact in this whole area. **It does not prevent tampering, it detects it.** Someone with delete rights on the bucket can still remove files; validation just makes the removal visible. Prevention is a different set of controls — restrictive bucket policies, delivery into an account the workload's administrators cannot touch, and versioning or object-lock style retention on the destination. **It does not cover the gap after logging stops.** If a principal calls `StopLogging` on the trail, the chain simply ends. Its final digest is intact and validation over the earlier window succeeds. The *absence* after that point is the finding, and you notice it only because you were watching for it — which is why the `StopLogging` and `DeleteTrail` calls are themselves management events worth alarming on. **It does not attest to the events' truth before CloudTrail wrote them.** It is integrity of the record in transit and at rest, not a claim that the recorded principal really was the human you think it was. ## Why it still matters Despite those limits, an auditor asks for it because it changes the argument from "trust the operator" to "verify the chain". It is cheap — no extra charge for the digest files beyond their trivial S3 storage — and it is a checkbox that costs one flag, so having it *off* on an audit trail is hard to defend. The strong answer pairs it with the controls that cover its blind spots: an organization-level trail so a member account cannot stop its own logging, delivery into a separate log-archive account so the people who might tamper do not hold write access to the destination, and alarms on the control-plane calls that would end the chain. Integrity validation proves the pages were not swapped; the surrounding design is what stops pages being torn out in the first place.

  • Validation over the last quarter passes cleanly, yet the auditor still says the evidence is incomplete. How is that possible?
    Integrity validation attests only to what CloudTrail delivered. If data events were never enabled, or the trail was single-region while activity happened elsewhere, the missing events were never generated — nothing was tampered with, so the chain is intact and the evidence is still incomplete. Completeness is a configuration question, integrity is a cryptographic one.
  • An attacker with administrator rights deletes an hour of log files. What does validation actually show?
    The digest for that hour still names the deleted files, so validate-logs reports them as missing rather than silently passing, and the next digest's back-reference exposes an attempt to remove the digest as well. Detection, not prevention — which is why the destination bucket should live in an account those administrators cannot write to.
  • Why is enabling integrity validation retroactively useless?
    The digests are produced at delivery time; there is no way to compute an AWS-signed chain over log files that were already written. Enabling it today starts the chain today, so a trail that has run for a year without it can never be validated for that year.

saying these in an interview costs you the question

  • Claims validation proves every API call was recorded
  • Thinks it prevents deletion rather than detecting it
  • Describes it as a per-event signature
  • Believes it can be applied to older logs retroactively
  • Confuses it with encrypting the logs with KMS

context

resolving links…