What CloudTrail Records

Every action in AWS is an API call, whether made from the console, the CLI, an SDK, or another service. AWS CloudTrail records those calls.

It is the audit trail that answers the essential security question: who did what, when, from where, and to which resource — the foundation of accountability in your account.

Each CloudTrail event records rich detail: the identity that made the call, the action (event name), the time, the source IP, the parameters, and the response.

This is enough to reconstruct exactly what happened during an incident and to attribute every change to a specific principal.

CloudTrail logs the last 90 days of management-event activity automatically in Event history, with no setup required.

For longer retention and full control, you create a trail that delivers events to S3 continuously. The exam expects you to know the default 90-day history versus a configured trail.

A trail captures events and delivers them to an S3 bucket for long-term storage, and optionally to CloudWatch Logs for real-time analysis.

You typically create a multi-region, organization-wide trail so no activity in any region escapes logging. This is the durable, queryable record incidents are investigated from.

The userIdentity element ties each call to a principal — an IAM user, an assumed role, the root user, or an AWS service.

During an investigation this is gold: it lets you trace a suspicious action back to the exact credential and session that performed it, even credentials assumed through a role chain.

It is easy to confuse the two. CloudTrail answers "who made which API call" — an audit log of actions.

CloudWatch answers "how is my system performing" — metrics, logs, and alarms about operational health. CloudTrail can send events to CloudWatch Logs, but their purposes are distinct.

A misconfigured single-region trail leaves blind spots an attacker can exploit by operating in an unmonitored region.

Enabling a multi-region trail ensures activity everywhere is captured in one place. AWS recommends this as a baseline so no region goes unaudited.

An attacker who can delete logs can hide their tracks. Protect CloudTrail with log file validation (digest files prove logs were not altered) and lock down the S3 destination with strict policies and Object Lock.

Store logs in a separate account so a compromise of the workload cannot reach them.

Deliver trail events to CloudWatch Logs and you can react in near real time: metric filters and alarms fire on specific actions, like a security group change or root login.

This bridges audit logging and active monitoring, turning the historical record into live detection.

A trail typically delivers events to S3 within about 15 minutes of the API call. It is durable and reliable but not instantaneous.

For faster reaction, stream to CloudWatch Logs where alarms can fire in near real time. Know that CloudTrail is an audit record first, not a millisecond-latency alerting system on its own.

CloudTrail underpins detection, investigation, and compliance. Many SCS-C02 scenarios hinge on enabling it correctly, protecting its logs, and querying them to find what happened.

If a question asks how to discover who deleted a resource or changed a policy, CloudTrail is almost always part of the answer.

Know what CloudTrail is for.

AWS CloudTrail is your account's audit trail, recording every API call with the caller's identity, action, time, source IP, and parameters. It keeps 90 days of management events in Event history by default; create a multi-region trail to S3 for durable, queryable logs. It differs from CloudWatch (performance) by answering who did what. Protect logs with validation, Object Lock, and a separate account, and stream to CloudWatch Logs for real-time alerts.