Lesson 24 of 30

CloudTrail & Audit Logging

Q: A production S3 bucket was briefly made public and then quickly fixed, but a security review needs to know exactly who made it public and when. Walk me through how you'd find that, and how you'd make sure this question is always answerable in the future.

A strong answer covers: Names CloudTrail specifically, distinct from CloudWatch, as the tool that records who performed which action; Explains that this is a management event (a policy/ACL change), logged by default, versus a data event; Notes that the default 90-day Event history isn't a durable long-term record, and that a configured trail delivering to S3 is what makes this reliably answerable months later; Mentions using specific event fields (identity ARN, source IP, timestamp, request parameters) to pin down the exact change.

CloudWatch answers 'is it broken?' CloudTrail answers 'who changed the thing that broke it, and when?' — the same account, a completely different question, and interviews expect you to know which tool answers which.

10 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A team wants to know exactly which identity changed an S3 bucket's policy overnight. Which AWS service actually answers that, and why not the other?

CloudTrail — it records who performed which API call, when, independent of whether anything is currently brokenCloudWatch — it monitors all account activity, including configuration changesEither works equally well, since both ingest data from every AWS service automatically

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on CloudTrail & Audit Logging

What interviewers actually ask about this, and what a strong answer has to cover.

A production S3 bucket was briefly made public and then quickly fixed, but a security review needs to know exactly who made it public and when. Walk me through how you'd find that, and how you'd make sure this question is always answerable in the future.

A strong answer covers

Names CloudTrail specifically, distinct from CloudWatch, as the tool that records who performed which action
Explains that this is a management event (a policy/ACL change), logged by default, versus a data event
Notes that the default 90-day Event history isn't a durable long-term record, and that a configured trail delivering to S3 is what makes this reliably answerable months later
Mentions using specific event fields (identity ARN, source IP, timestamp, request parameters) to pin down the exact change

Likely follow-ups

What would CloudTrail show you if the action was taken through the console using temporary credentials from an assumed role — and what would it not tell you?
Would you also enable S3 data events for this bucket going forward? What's the tradeoff in doing that for every bucket in the account?

Practice these with the AI interviewer →

The plain-language idea

CloudTrail is AWS's audit log: an immutable record of every API call made against an account — who made it (which user or role), what action they took, when, from what source IP, and whether it succeeded. It exists independent of whether anything is currently healthy or broken; it's a historical record of activity, not a monitor of state.

That's the real distinction from this track's CloudWatch lesson. CloudWatch collects logs, metrics, and alarms about running systems to answer "is this within normal range right now?" CloudTrail records account-level activity to answer "who did this, and when?" A CloudWatch alarm can tell you error rates spiked at 2am; only CloudTrail can tell you a bucket policy was changed at 1:58am, by which identity, from which IP.

Every recorded action falls into one of two categories:

Management events — control-plane actions: creating a bucket, attaching an IAM policy, launching an instance. Logged by default, at no extra setup.
Data events — data-plane actions on the resources themselves: an individual S3 GetObject, a Lambda invocation. Far higher volume, and not logged by default — enabling them is an explicit, opt-in decision because of the cost and volume involved.

See it in a real thing: tracing a bucket policy change back to its source

A production S3 bucket's access policy changed overnight and the app started throwing 403s. CloudWatch's error-rate alarm fired and named the affected service — but not who touched the bucket. CloudTrail's Event history is where that answer lives: filtering for PutBucketPolicy events against that specific bucket name returns an event record naming the exact IAM identity (a user or an assumed role's ARN), the source IP, the timestamp, and the request parameters — including the old and new policy document.

{
  "eventName": "PutBucketPolicy",
  "eventTime": "2026-08-12T20:58:03Z",
  "userIdentity": { "arn": "arn:aws:iam::123456789012:role/ci-deploy" },
  "sourceIPAddress": "203.0.113.42",
  "requestParameters": { "bucketName": "user-uploads" }
}

That single event turns "something changed" into "this exact identity changed this exact setting at this exact time" — the difference between guessing and knowing.

What people usually miss

Watch out

The 90-day default Event history isn't a durable audit record. It's a convenience view for recent activity, not a long-term store — a real audit or compliance requirement needs an explicitly configured trail delivering to S3, not reliance on the default.
Data events are opt-in, and most accounts never enable them. Object-level S3 access or per-invocation Lambda activity isn't logged unless someone deliberately turns it on for that resource — which means "who actually read this specific file" is often a question CloudTrail can't answer unless data events were already enabled before the fact.
Failed attempts are logged too, and they're genuinely useful signal. An AccessDenied event isn't noise to filter out — repeated failed attempts at an action an identity doesn't have permission for is exactly the kind of pattern that indicates a misconfigured pipeline or a compromised credential probing for what it can reach.
CloudTrail records that an action happened, not why. It has no concept of intent, ticket numbers, or business justification — correlating "this policy changed" with "because of this planned deployment" is still on the team, usually via change-management process, not something the audit log infers on its own.

Why this matters in interviews

"How would you find out who deleted this resource, and when?" is a real, common question, and naming CloudTrail specifically — not CloudWatch, not vaguely "the logs" — while explaining the management-vs-data-event distinction is what separates someone who's actually used AWS's audit tooling from someone reasoning about monitoring in the abstract.