You are studying for exam objective 3.1: designing and implementing logging and monitoring with CloudTrail. Before you can design security monitoring for a cloud environment, you need to understand the tool that records every action your cloud account takes. This chapter explains CloudTrail logging and management events in plain English, so you can answer exam questions about what gets recorded, how to turn it on, and why it's the foundation of cloud security.
Jump to a section
A simple way to picture CloudTrail Logging and Management Events
Have you ever walked into a large office building and signed a visitor logbook at the front desk?
That logbook is a simple but powerful tool. It records exactly who entered, when they came in, who they were visiting, and when they left. If someone later claims they never entered the building on Tuesday, you can check the logbook and prove them wrong. If a security guard wants to know why a package was delivered to the wrong floor, the logbook shows which courier signed in at that time.
Now imagine that instead of a paper logbook, you have a digital one that automatically records every single action taken by anyone with a keycard — every door opened, every badge swipe, every time someone tried to enter a restricted area and was denied. That's what AWS CloudTrail is for your cloud environment.
In the cloud, you don't have a physical reception desk. Instead, you have virtual accounts, services, and resources. CloudTrail is the automated, tamper-proof logbook that records every action taken inside your AWS account. It doesn't just note the action — it notes who performed it (a user, a service, or a program), exactly when it happened, what resource was involved, and whether it succeeded or failed. The “Management Events” are the high-level actions like creating a new user, changing a security setting, or deleting a storage bucket. These are the equivalent of the building's most important security decisions — the ones that could let someone in or lock someone out.
AWS CloudTrail is a service that records every action taken in your AWS account. Think of it as a surveillance camera for your cloud. Every time someone or something makes a request to AWS — whether through the web console, a command-line tool, a software program, or another AWS service — CloudTrail captures that request as an event.
An "event" is just a record of a single action. Each event includes: the name of the action (like "CreateUser" or "DeleteBucket"), who made the request (a user, a role, or another service), the time it happened (down to the second), the source IP address from which the request originated, the AWS region where the request was made, and the outcome (whether it succeeded or failed).
CloudTrail organises events into two main categories: management events and data events. This chapter focuses on management events, which the SCS-C02 exam loves to test.
Management events are actions that change your AWS environment's configuration or security settings. These are the most important events to monitor because they involve creating, modifying, or deleting resources. Examples include:
Creating a new Amazon S3 storage bucket
Changing security group rules (firewall rules for virtual servers)
Deleting an IAM user (a user who can access your account)
Modifying a VPC (virtual private cloud) subnet
Rotating encryption keys (keys that protect your data)
Launching (starting) or terminating (stopping) an EC2 virtual server
Management events are always recorded by default when you enable CloudTrail in your account. You cannot turn them off — they are the first thing CloudTrail tracks. They are free to store for the most recent 90 days in the CloudTrail Event History console. After 90 days, they disappear unless you create a "trail" that saves them to an S3 bucket or CloudWatch Logs for longer storage.
Data events, by contrast, record actions performed on resources within those services. For example, if you have an S3 bucket, a management event records when the bucket is created, but a data event records when someone uploads a file to that bucket. Data events are optional and cost extra because there are many more of them.
CloudTrail can record events from every AWS region and aggregate them into a single location. This is called a "multi-region trail". For the exam, remember that if you want to monitor activity across all regions, you must enable a multi-region trail.
When you create a trail, you specify an S3 bucket where the log files will be delivered. You can also send the events to CloudWatch Logs for real-time alerting. For example, you can set up an alarm that triggers whenever someone tries to delete a security group, so you get notified immediately.
CloudTrail is not the same as server logs. Server logs record what happens inside an operating system (like which files were accessed or which commands were typed on a virtual machine). CloudTrail records what happens to the AWS environment itself (like who changed a firewall rule or launched a new server). Both are important, but CloudTrail focuses on the control plane — the infrastructure that manages your cloud resources.
Why does this matter for security? If an attacker gains access to your AWS account and deletes a database or changes a security setting, CloudTrail is the only way to find out what happened. It provides an immutable record that cannot be altered or deleted by the attacker (if you lock the trail with appropriate permissions). Security teams use CloudTrail for incident response, audits, compliance, and forensic investigations.
CloudTrail also integrates with AWS organisations, allowing you to log events from all accounts in your organisation into a single central bucket. This is called an "organisation trail" and is a key concept for managing security across multiple accounts.
For the SCS-C02 exam, you need to know the difference between management events and data events, how to enable a trail, how to interpret a CloudTrail log entry, and how to use CloudTrail with other services like CloudWatch and S3 for monitoring and alerting.
Enable CloudTrail
The first step is to create a trail in the AWS CloudTrail console. You give the trail a name and choose whether it applies to all regions (multi-region) or just one. For security, you should always choose multi-region so that activity in any region is captured.
Choose Storage Destination
You specify an S3 bucket where CloudTrail will deliver log files. You can also choose to send events to CloudWatch Logs for real-time monitoring. The S3 bucket must have a policy that grants CloudTrail permission to write to it.
Select Log Event Types
You choose which events to log. Management events are selected by default. If you need data events (like S3 object-level operations or Lambda invocations), you must explicitly enable them. Be aware that data events incur costs.
Configure Log File Integrity Validation
Optionally, you can enable log file integrity validation. This creates a SHA-256 hash of each log file and stores it in a separate digest file. You can use this to verify that log files have not been modified after they were created.
Set Up Alerts with CloudWatch
If you sent logs to CloudWatch Logs, create metric filters to detect specific actions. For example, a filter for the 'DeleteBucket' event can trigger an SNS notification to your security team. This step ensures you are alerted to critical changes in real-time.
Test and Verify
Perform a test action, such as creating a test S3 bucket, then check the CloudTrail Event History console to confirm the event appears. Also verify that the log file was delivered to your S3 bucket and that any alerts you configured triggered correctly.
An IT security engineer at a mid-sized company is responsible for monitoring the AWS environment. One Monday morning, the company's finance team reports that a critical S3 bucket containing customer billing data has been deleted. The bucket is named "finance-billing-prod" and held sensitive information.
The engineer's first step is to open the AWS CloudTrail Event History console in the us-east-1 (Virginia) region, because that's where the bucket was created. She knows that management events are recorded by default, and the deletion of an S3 bucket is a management event. She filters the event history by event name "DeleteBucket" and sets the time range to the past 48 hours.
She finds a single event matching her query. Clicking on it, she sees the following details:
User identity: A user named "john.doe" authenticated with an IAM user credentials.
Event time: Sunday, 3:14 AM UTC.
Source IP address: 203.0.113.42 (a public IP address).
User agent: Console (meaning the action was performed through the AWS web management console).
Request parameters: The bucket name was "finance-billing-prod".
Response elements: The operation succeeded.
She immediately knows that an employee named John Doe deleted the bucket at an unusual hour. She contacts him and learns that John was testing a script that accidentally targeted the wrong bucket.
But the story doesn't end there. The engineer wants to ensure this never happens again. She creates a new CloudTrail trail that delivers events to a central S3 bucket in a different account (for tamper-proof storage). She also configures CloudTrail to send events to Amazon CloudWatch Logs.
Inside CloudWatch Logs, she creates a metric filter that looks for any event named "DeleteBucket". She attaches an alarm to this metric that sends an email to the security team whenever a bucket deletion occurs. Now, anyone who deletes a S3 bucket triggers an immediate alert.
Next, she enables a multi-region trail so that events from all AWS regions are captured. Her company has offices in Europe, Asia, and the US, and resources are deployed in multiple regions. Without a multi-region trail, an attacker deleting resources from ap-southeast-1 (Singapore) would go unnoticed because the trail only covers us-east-1.
She also sets up an S3 lifecycle policy that moves log files to Glacier (a low-cost archiving service) after 90 days and deletes them after 365 days, to comply with the company's data retention policy.
Finally, she tests the setup by deleting a test bucket. She confirms that the event appears in CloudTrail Event History within 15 minutes, that a log file is delivered to the S3 bucket, and that the CloudWatch alarm triggers within 5 minutes.
In this real-world scenario, CloudTrail was the first tool the engineer reached for. Without it, she would have had no clue who deleted the bucket, when it happened, or how to prevent it from happening again. The engineer uses CloudTrail daily for monitoring, auditing, and troubleshooting, and it is a cornerstone of every AWS security professional's toolkit.
The SCS-C02 exam tests CloudTrail logging and management events heavily. Expect to see questions that require you to identify what type of event an action is, or to choose the correct way to enable logging for a specific scenario.
Here is exactly what the exam focuses on:
Management vs. data events: This is the single most tested distinction. Memorise it. A management event is any action that creates, modifies, or deletes an AWS resource. A data event is an action performed on the content of a resource, like reading a file from S3 or invoking a Lambda function.
Which events are free: Management events are always enabled and free for the first 90 days. Data events are charged per million events.
What a trail can store: A trail delivers log files to an S3 bucket. It can also deliver events to CloudWatch Logs for real-time analysis.
What CloudTrail cannot log: CloudTrail does not log actions performed inside an operating system (like commands typed on an EC2 instance). It only logs actions against the AWS API.
The difference between CloudTrail Event History and a trail: Event History shows the last 90 days of management events and is free. A trail is a configuration that delivers events to a destination like S3 or CloudWatch Logs for long-term storage or real-time processing.
Multi-region vs. single-region trails: The exam will test that a trail created in one region only captures events from that region unless you check the "Apply to all regions" option.
Organisation trails: If you have multiple AWS accounts under AWS Organisations, you can create a trail at the organisation level that logs events from all member accounts.
Immutability: You must prevent attackers from disabling or modifying CloudTrail. The exam tests how to lock a trail using S3 bucket policies and IAM permissions to prevent deletion or modification.
Log file integrity validation: CloudTrail can create a SHA-256 hash of each log file and store it in a separate S3 bucket. This lets you verify that a log file has not been tampered with. The exam may ask about this feature.
Common traps on the exam:
A question will describe a scenario where a user accesses objects in an S3 bucket, and ask whether this is a management or data event. The correct answer is a data event, because accessing the content of an object is not a management action.
Another trap: A question asks how to monitor API calls from a specific IAM user. The answer is to use CloudTrail. Not CloudWatch (which monitors performance metrics), not VPC Flow Logs (which monitor network traffic), and not AWS Config (which monitors resource configuration changes).
The exam loves to ask: "Which AWS service should you use to record who created a new EC2 instance?" The answer is always CloudTrail.
They will also test that you need to enable CloudTrail in every region individually OR create a multi-region trail. One region's trail does not cover another region by default.
Key definitions to memorise:
Event: A record of an API call made to AWS.
Trail: A configuration that delivers events to a storage location.
Management event: An action that affects AWS resources (create, modify, delete).
Data event: An action that affects the content of a resource (read, write).
Multi-region trail: A trail that captures events from all AWS regions.
Organisation trail: A trail that captures events from all accounts in AWS Organisations.
CloudTrail records every API call made to your AWS account as an event, providing an immutable audit trail for security and compliance.
Management events are logged by default and are free for 90 days in Event History; they cover actions that create, modify, or delete AWS resources.
Data events are not logged by default and cost extra; they track actions on resource content, like reading or writing objects in S3.
A single-region trail only captures events from the region in which it was created; you must create a multi-region trail to cover all regions.
CloudTrail logs can be delivered to an S3 bucket for long-term storage and to CloudWatch Logs for real-time monitoring and alerting.
To prevent attackers from disabling or modifying CloudTrail logs, you must protect the trail with IAM policies, S3 bucket policies, and enable log file integrity validation.
CloudTrail cannot log operating system actions inside EC2 instances; for that you need separate tools like CloudWatch Agent or Amazon Inspector.
An organisation trail in AWS Organisations captures events from all member accounts into a single central S3 bucket.
These come up on the exam all the time. Here's how to tell them apart.
Management Events
Record actions that create, modify, or delete resources (e.g., 'CreateBucket')
Enabled by default, free for 90 days in Event History
Low volume, typically fewer than 10,000 per day in a medium account
Data Events
Record actions on the content of resources (e.g., 'GetObject' in S3)
Not enabled by default, charged per million events
High volume, can be millions per day in active accounts
CloudTrail
Records individual API calls (who, what, when, from where)
Focuses on 'who did something' (audit trail)
Delivers logs to S3 or CloudWatch Logs
AWS Config
Records the state of resources over time (compliance)
Focuses on 'what changed' (configuration history)
Stores snapshots and configuration history in S3 and can trigger rules
Single-Region Trail
Only captures events from the region where it was created
Cost is lower but you must create separate trails for other regions
Cannot be used to monitor global activity from one place
Multi-Region Trail
Captures events from all AWS regions automatically
Cost is slightly higher but simplifies management
Recommended for security and compliance to ensure no blind spots
CloudTrail Event History
Free, always-on, and cannot be disabled
Stores only management events for 90 days
Cannot send events to CloudWatch Logs or S3
CloudTrail Trail
Optional configuration that you create and manage
Can store both management and data events indefinitely in S3
Can send events to CloudWatch Logs for real-time analysis
Mistake
CloudTrail logs everything that happens inside an EC2 server, like who logged in to the operating system and what commands they ran.
Correct
CloudTrail only logs actions made against the AWS API, such as creating or stopping an EC2 instance. It does not log anything that happens inside the operating system of that instance. For OS-level logging, you need services like Amazon Inspector or custom logging agents.
Beginners often confuse the cloud infrastructure (the AWS account) with the server operating system. They assume that 'logging' means everything, but AWS draws a clear line between the control plane (CloudTrail) and the data plane (server logs).
Mistake
Once you create a CloudTrail trail, it automatically captures events from all AWS regions.
Correct
By default, a trail only captures events from the region where it was created. You must explicitly select the option to 'Apply to all regions' when creating the trail to make it a multi-region trail.
Many people assume cloud services are global by default, but AWS requires explicit opt-in for cross-region features. This misconception is common because some other AWS services do work globally without configuration.
Mistake
CloudTrail logs are immediately available in real-time, like a live video feed.
Correct
CloudTrail delivers log files to your S3 bucket approximately every 5 to 15 minutes on average. It is not instantaneous. Event History in the console is near real-time (a few minutes delay), but it only stores 90 days of data.
The term 'logging' often implies instant recording, but CloudTrail operates on a batch delivery model. People expect real-time updates because many applications they use daily (like email) are near-instant.
Mistake
Data events are automatically logged for all AWS services, just like management events.
Correct
Data events are not logged by default. You must explicitly enable them when creating a trail, and they incur additional charges per million events. Management events are the only ones enabled by default.
The word 'data' sounds similar to 'management', but AWS treats them differently. Beginners often think 'all events are logged' because the exam material emphasises CloudTrail's comprehensiveness.
Mistake
You can delete CloudTrail logs from your S3 bucket to hide malicious activity, and no one will know.
Correct
CloudTrail logs can be configured with S3 bucket policies and IAM permissions to prevent deletion. Additionally, you can enable log file integrity validation to create cryptographic hashes that prove log files have not been tampered with. Attempting to delete logs will also generate a CloudTrail event.
This misconception comes from thinking cloud logs are like personal computer files — easy to delete. In a well-architected security environment, logs are protected so that even the admins cannot easily delete them without detection.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudTrail records who did what and when in your AWS account (audit and compliance). CloudWatch collects performance data, metrics, and logs from your running resources. You can send CloudTrail logs to CloudWatch for real-time alerting.
Yes, any change to an S3 bucket policy is a management event (the action is 'PutBucketPolicy'). CloudTrail will record who made the change, from which IP address, and when.
CloudTrail Event History stores management events for the last 90 days for free. After that, they are automatically deleted unless you have created a trail that delivers them to an S3 bucket for long-term storage.
Yes. If an AWS service, like AWS Lambda or Amazon EC2 Auto Scaling, performs an action on your behalf, CloudTrail records it. The user identity will show the service name, such as 'lambda.amazonaws.com'.
It could be a data event that you did not enable. Check whether the action is a management or data event. Also, ensure you are looking in the correct region — CloudTrail only shows events from regions where it is enabled.
Yes. Use S3 bucket policies to deny 's3:DeleteObject' and 's3:DeleteBucket' actions to all users except a specific admin role. Also, enable log file integrity validation to detect tampering.
You've finished CloudTrail Logging and Management Events. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?