Reading the error fields in a CloudTrail finding
An API name does not show the whole result. A note on failed requests, target identities and follow-up checks.
Reading series: August 2026. This grouping describes the topic or work discussed, not the publication date.
This October note follows the CloudTrail reading series. It is about interpreting the output of my scanner, rather than adding another rule.
An event named StopLogging is worth checking. The name alone does not tell me whether the request succeeded. The request may have been denied.
Read more than the event name
CloudTrail records fields such as eventName, userIdentity, requestParameters and error information when it applies. The event reference describes these fields.
For a logging operation, I need the trail involved, who made the request and whether it completed. For an IAM change, the identity making the request and the user or role being changed may be different.
A summary is easier to read than a full export, but the original event still matters. It can contain details that the finding does not show.
What the scanner can tell me
cloudtrail-quickscan reports rule matches with severity and event context. It reads files locally. It does not fetch a resource’s previous state or compare the action with a change ticket.
I use severity to indicate which operations deserve attention. A high label is not enough to conclude that an account was compromised. A failed request can also deserve attention, even though it did not make the requested change.
When reviewing a rule, I need to check how it handles errorCode. Two similar synthetic inputs, one with an error and one without it, can make that behavior easier to inspect. The current tests show the cases actually covered; this note does not add new coverage.
The investigation notes suggest looking at nearby events and the actor’s expected activity. A finding gives me a place to start. The remaining evidence comes from the investigation.