Auditing in the cloud means answering two big questions: “Who did what, and when?” and “Is my infrastructure still following the rules?” For the SOA-C02 exam, you need to know how AWS CloudTrail and AWS Config work together to give you that complete picture. Without them, you would be flying blind when something goes wrong or when an auditor asks for proof of compliance.
Jump to a section
A simple way to picture Auditing with AWS CloudTrail and AWS Config
A security camera system in a busy warehouse monitors every single movement. Each camera records a timestamped video of who enters, what they carry, and where they go. The system’s logbook enforces a rule: no one may enter the restricted server room without a badge scan, and the logbook automatically checks that rule against every entry. The warehouse manager uses the camera footage later to answer questions like, “Who accessed the inventory last Tuesday?” and “Did anyone break the rule about entering the server room alone?” The camera’s footage cannot be deleted or altered by anyone except the security chief, who stores it in a locked cabinet for years. The logbook, meanwhile, sends an alert whenever someone tries to enter the server room without scanning their badge, and it keeps a record of every rule violation.
This maps directly to AWS CloudTrail and AWS Config. CloudTrail is the security camera: it records every action taken in an AWS account, like who launched an EC2 instance or who deleted an S3 bucket. AWS Config is the logbook: it checks your AWS resources against rules (e.g., “no S3 buckets should be public”) and alerts you when something breaks a rule. Together, they give you the full picture of what happened (CloudTrail) and whether your infrastructure stayed compliant (AWS Config).
AWS CloudTrail is a service that records every API call made in your AWS account. An API call is a request sent to AWS to perform an action, like launching an EC2 instance or creating an S3 bucket. CloudTrail captures the identity of the caller (which IAM user or role), the time of the call, the source IP address, and the request parameters.
CloudTrail delivers these records as log files called “events” to an S3 bucket you choose. You cannot disable CloudTrail entirely — it’s always on for the most recent 90 days of events, visible in the CloudTrail Event History console. But for long-term retention, you must create a trail. A trail is a configuration that tells CloudTrail where to deliver events and which regions or services to cover. You can have a single-region trail or a multi-region trail. A multi-region trail collects events from every AWS region into one S3 bucket, which is vital for global auditing.
CloudTrail supports two types of events: management events and data events. Management events cover operations on AWS resources, such as creating a VPC or deleting an IAM user. These are recorded by default. Data events cover operations *within* a resource, such as reading an object in an S3 bucket or invoking a Lambda function. Data events are not recorded by default because they generate a huge volume of logs. You must explicitly enable them for specific resources. - Management events: record control-plane operations like CreateVpc, DeleteUser, AttachRolePolicy. These are free and enabled by default for trails. - Data events: record data-plane operations like GetObject on S3, Invoke on Lambda, or PutObject on S3. These incur cost and must be enabled per resource.
CloudTrail also supports Insights events. CloudTrail Insights uses machine learning to detect unusual API activity, such as a sudden spike in failed API calls or an unexpected surge in instance launches. You must enable Insights on a trail to get these events.
Now let us look at AWS Config. AWS Config is a service that continuously monitors and records the configuration state of your AWS resources. It answers the question: “What does my infrastructure look like right now, and has it changed?” AWS Config takes a snapshot — called a configuration item — of each supported resource every time a change occurs. It stores these snapshots in a history of changes, so you can see what an EC2 instance looked like on Monday versus Wednesday.
AWS Config also lets you define rules. Rules are checks you write — or choose from a library of managed rules — that say things like “All S3 buckets must have versioning enabled” or “All EC2 instances must be in a specific VPC.” AWS Config evaluates your resources against these rules and reports either “Compliant” or “Noncompliant.” If a resource becomes noncompliant, AWS Config can trigger an automated action, such as sending an SNS notification or invoking a Lambda function to fix the problem.
AWS Config provides two key features: configuration history and configuration snapshots. Configuration history is a chronological record of every change to a resource. Configuration snapshots are point-in-time reports of all resources in a region. You can also use AWS Config Aggregators to view compliance data across multiple accounts and regions.
CloudTrail and AWS Config complement each other. CloudTrail tells you *who* did something and *when*. AWS Config tells you *what* the current state of the resource is and *whether* it violates a rule. For example, if a developer deletes an S3 bucket, CloudTrail logs that action (the “delete bucket” API call). AWS Config then reports that the bucket no longer exists, and any rule checking for that bucket becomes Noncompliant. Together, they give you a complete audit trail of actions and resulting configurations.
Create a Multi-Region Trail
Open CloudTrail, choose ‘Create trail’, give it a name, and select ‘Apply to all regions’. This ensures events from every region are logged to a single S3 bucket. For the SOA-C02 exam, multi-region trails are important for global auditing requirements.
Enable Data Events for S3
Under the same trail, select ‘Data events’ and choose ‘S3’ as the source. This logs every read and write to objects in your S3 buckets. Without this step, CloudTrail will only record bucket-level operations (management events), not object-level operations that are critical for security audits.
Enable CloudTrail Insights
In the trail configuration, select ‘CloudTrail Insights’. This enables the service to analyse normal API activity and alert you when unusual patterns occur, such as a spike in failed login attempts. The exam tests that Insights is an optional add-on to standard logging.
Set Up AWS Config Recorder and Rules
Open AWS Config, click ‘Get started’, and select all resource types in your region. Then add a managed rule, such as ‘s3-bucket-public-read-prohibited’. AWS Config will continuously evaluate your resources against that rule and report compliance status. The exam tests that you must also set up an S3 bucket for configuration snapshots and history.
Configure AWS Config Notifications
In AWS Config, set up an Amazon SNS topic for compliance change notifications. This sends you an email (or SMS) whenever a resource becomes noncompliant. This step is not required for basic auditing, but the exam tests that you can automate responses to compliance violations.
Generate a Compliance Report for Audit
In AWS Config, use the ‘Compliance’ dashboard to filter by rule or resource. For a point-in-time snapshot, you can also trigger a configuration snapshot delivery to your S3 bucket. This step shows the auditor proof of compliance — a key exam scenario.
Imagine you work as a SysOps administrator for a company called FinSecure, an online payments platform that must comply with PCI DSS (a security standard for handling credit card data). Your boss tells you that an external auditor will visit next month and expects to see proof that no one has tampered with the system. You need to show exactly who accessed sensitive data and whether your infrastructure ever drifted from the required security settings.
Step one: you enable AWS CloudTrail with a multi-region trail. You choose an S3 bucket in the US East (N. Virginia) region to store all logs. You enable log file integrity validation to prove that no one has tampered with the log files. You also enable CloudTrail Insights to detect any unusual patterns, like a sudden flurry of failed login attempts.
Step two: you configure AWS Config. You first specify which resources to record — you select all supported resources in the region where FinSecure runs its payment workload. You then create a few custom rules: - “s3-bucket-ssl-requests-only” to ensure all S3 buckets in the payment account enforce encryption in transit. - “ec2-instance-no-public-ip” to ensure no EC2 instance in the processing subnet has a public IP address. - “iam-user-mfa-enabled” to check that every IAM user with a password has multi-factor authentication (MFA) enabled. Step three: you set up AWS Config to send notifications via Amazon SNS whenever a resource becomes noncompliant. For example, if someone accidentally makes an S3 bucket public, AWS Config triggers an SNS message, which you receive as an email. You also configure AWS Config to deliver configuration snapshots to an S3 bucket every six hours, giving you a regular record of the infrastructure state.
Step four: the auditor arrives. You open the CloudTrail console and run a query on the events for the past 90 days. You filter by “DeleteBucket” to show that only the authorised storage administrator, Jane, deleted a test bucket three weeks ago. You then open AWS Config and generate a compliance report. The report shows every resource, the rules applied to it, and whether it passed. The auditor sees that all resources are compliant, proving FinSecure has maintained security controls.
Step five: you also use AWS Config to review the configuration history of the EC2 instance that processes transactions. You can see that last week, the security team changed its security group to allow only HTTPS traffic from the internal load balancer — a documented change. AWS Config’s timeline view shows the exact before-and-after configuration, satisfying the auditor’s request for evidence of a change control process.
This is the real-world daily work of a SysOps admin: enabling these services, setting up trails and rules, responding to compliance alerts, and generating reports for audits. Without CloudTrail and AWS Config, you would have no reliable way to prove compliance or investigate incidents.
The SOA-C02 exam loves to test your understanding of the differences between CloudTrail and AWS Config, the types of events each service records, and how to configure them correctly. The exam questions are scenario-based: you get a short description of a business requirement and have to pick the right service or configuration. You will not be asked to write a CloudFormation template or recall obscure CLI commands, but you must know the core features and the gotchas.
Concepts the exam tests frequently:
- The difference between management events and data events in CloudTrail. A typical question: “A company wants to log all ‘GetObject’ API calls on a specific S3 bucket. Which type of CloudTrail event should be enabled?” The correct answer is Data events. - Multi-region versus single-region trails. The exam may present a scenario where a company operates in multiple regions and needs a single log destination. The correct answer is a multi-region trail. - Log file integrity validation. The exam might ask what feature of CloudTrail prevents tampering with log files. Correct answer: Digest files created by log file integrity validation. - CloudTrail Insights. Questions might ask what Insights detects — abnormal API call patterns. Not the content of the calls, but the volume and rate. - AWS Config managed rules versus custom rules. A question might describe a rule that exists in the managed rule library (e.g., “s3-bucket-public-read-prohibited”) and ask whether you need to write a custom rule. Answer: Use the managed rule. - Configuration recorder: you must know that AWS Config only records resources in the region where it is enabled. To cover all regions, you must enable AWS Config in each region or use an aggregator. - Aggregators: the exam tests how to view compliance across multiple accounts or regions using AWS Config Aggregators, not by looking at each account’s console separately. - The exam also tests that CloudTrail is eventually consistent — there can be a short delay (up to 15 minutes) before events appear in the trail. AWS Config evaluations happen near real-time, but configuration items may take a few minutes. Common traps the exam sets:
- They ask about “who made a change” and the answer is CloudTrail, but then they add that the company also needs to know the “current state of the resource.” Many candidates pick only CloudTrail — the correct answer is CloudTrail AND AWS Config together. - They describe a scenario where you need to check if an EC2 instance was ever launched with a public IP address. Your instinct might be CloudTrail, but the exam wants AWS Config’s configuration timeline so you can see the instance’s configuration at launch time. - They ask about “auditing changes to security groups” — both services could help. The key clue: if the question says “see the change history of the resource itself (before and after),” pick AWS Config. If the question says “see who made the change and when,” pick CloudTrail. - The exam sometimes presents a false choice between “CloudTrail Log File Integrity” and “AWS KMS.” Both can protect log files, but the exam expects you to know that log file integrity validation uses SHA-256 hashing and digital signatures, not KMS. Key definitions to memorise:
Trail: the configuration that delivers CloudTrail events to an S3 bucket and optionally to CloudWatch Logs.
Configuration Recorder: the AWS Config component that collects configuration data from resources.
Configuration Item: a record of a resource’s configuration at a point in time.
Compliance Type: the result of an AWS Config rule evaluation (Compliant, Noncompliant, or Not Applicable).
Multi-region trail: a single trail that logs events from all regions.
CloudTrail records who performed an action, when, and from where — it is the who, what, when, and where of API calls.
AWS Config records the configuration state of resources and evaluates them against rules — it answers what the infrastructure looks like and if it complies.
Management events in CloudTrail are free and logged by default; data events are chargeable and must be enabled explicitly.
AWS Config’s configuration history allows you to view a resource’s state before and after a change, but not who made the change.
CloudTrail Insights detects unusual API call patterns using machine learning and requires a trail to be enabled.
A multi-region trail collects logs from all AWS regions into one S3 bucket, while a single-region trail only covers the region where it is created.
AWS Config managed rules are pre-built checks; custom rules use AWS Lambda to define complex logic.
Log file integrity validation in CloudTrail uses cryptographic hashing to prove that logs have not been tampered with.
These come up on the exam all the time. Here's how to tell them apart.
CloudTrail
Records API calls (who, what, when, from where)
Logs management events by default; data events optional
Primary use: security investigation and incident response
AWS Config
Records resource configuration state (what the resource looks like)
Continuously evaluates resources against compliance rules
Primary use: compliance audits and configuration drift detection
Management Events
Record actions on AWS resources (e.g., CreateVpc, DeleteUser)
Enabled by default in CloudTrail trails
Lower volume, no additional cost per event for trails
Data Events
Record actions inside resources (e.g., GetObject on S3, Invoke on Lambda)
Must be explicitly enabled for each resource type
High volume, incur additional cost per event
Multi-Region Trail
Logs events from all AWS regions into one S3 bucket
Requires one trail to be created in a single region; AWS handles cross-region delivery
Recommended for global auditing and compliance
Useful when all resources are in one region
Single-Region Trail
Logs events only from the region where the trail is created
Simple to set up for a single-region workload
Not suitable for multi-region environments
Mistake
CloudTrail automatically logs all API calls forever with no extra configuration.
Correct
CloudTrail retains the last 90 days of events in Event History, but for longer retention, you must create a trail that delivers logs to an S3 bucket.
Because Event History exists by default, beginners assume that means permanent logging. The exam tests that trails are needed for long-term storage.
Mistake
AWS Config can detect unexpected API calls, like someone deleting a resource.
Correct
AWS Config records configuration changes, not who made them. It shows the new state after a change, but not the identity of the caller. That is CloudTrail’s job.
Both services track changes, so beginners conflate them. The exam emphasises that CloudTrail shows the who, AWS Config shows the what.
Mistake
Once you enable a trail, it immediately captures all past API calls.
Correct
CloudTrail only captures events that occur after the trail is created. It does not retroactively log previous events.
This is a common misunderstanding about logging services. Exam scenario questions often require you to know that enabling a trail does not backfill data.
Mistake
AWS Config works across all AWS regions automatically when you enable it in one region.
Correct
AWS Config must be enabled in each region individually, or you must use an aggregator to see a cross-region view.
AWS Config is region-specific by design. Beginners expect a global toggle. The exam tests this regional limitation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, CloudTrail captures all API calls made through the console, AWS CLI, SDKs, and any other service that uses the AWS API. Each console click is translated into an API call behind the scenes, and that call is logged.
Yes, but only for the last 90 days of events visible in the Event History dashboard. To store logs beyond 90 days, you must create a trail that delivers events to an S3 bucket.
A managed rule is a pre-built rule provided by AWS (e.g., ‘restricted-ssh’). A custom rule is one you write using an AWS Lambda function to evaluate resources against your own logic. Both check for compliance.
No, not by default. But you can set up auto-remediation by attaching an AWS Systems Manager Automation document or a Lambda function to a rule. The rule’s evaluation result triggers the remediation action.
Only if you enable data events for that S3 bucket in your trail. By default, CloudTrail logs management events (like creating or deleting a bucket) but not data events (like GetObject or PutObject).
No. AWS Config shows the change in configuration (e.g., the security group rules changed from A to B), but it does not record the identity of the person who made the change. You need CloudTrail for that information.
You've just covered Auditing with AWS CloudTrail and AWS Config — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?