Audit and Configuration Tracking with CloudTrail, Config, and Centralized Logging for SCS-C03
_Category: Logging & Monitoring_
The first question after any security incident is always: "Do you have logs?" Without logs, you cannot know what happened. With tampered logs, you cannot trust what you know. SCS-C03 repeatedly tests "how you record, how you protect, and how you use" audit data. This post walks through the full audit and logging architecture — CloudTrail, Config, CloudWatch Logs, EventBridge, Kinesis Data Firehose, Athena, VPC Flow Logs, and Audit Manager — so you leave with a clear mental model, not just a list of facts.
---
What Auditability Means and What SCS-C03 Is Really Testing
Auditability means being able to prove — after the fact — who did what, when, from where, and how. A trustworthy audit record must satisfy three properties: completeness (nothing is missed), integrity (nothing is altered), and availability (you can retrieve it when you need it).
SCS-C03 recycles a handful of high-frequency scenario patterns:
"All API calls must be recorded and any tampering must be detectable" → CloudTrail + Log File Integrity Validation + S3 Object Lock "Before-and-after configuration changes must be tracked when a resource is modified" → AWS Config Configuration Item "The security team must be notified the moment a specific API call occurs" → CloudTrail + EventBridge + SNS "Logs from multiple accounts must be aggregated in a single location" → Log Archive Account + Kinesis Data Firehose
CloudTrail and Config answer fundamentally different questions. CloudTrail asks "what happened?" — it is a history of API actions. Config asks "what does this resource look like right now?" — it is a snapshot and change history of resource configuration. The exam deliberately presents similar-sounding scenarios to blur this distinction, so a crisp understanding of each service's role is essential.
---
CloudTrail's Three Event Types: Management, Data, and Insights Events
Think of CloudTrail as a building access logbook — but one that has three separate registers, each tracking a different class of entry.
| Event Type | What Is Recorded | Enabled by Default | Examples | |------------|------------------|--------------------|----------| | Management Events | Resource management APIs (control plane) | Yes — Event History free for 90 days | CreateBucket, RunInstances, AuthorizeSecurityGroupIngress | | Data Events | Data-plane access within resources | No — must be explicitly enabled | S3 GetObject/PutObject, Lambda Invoke, DynamoDB GetItem | | Insights Events | Automatic detection of anomalous API activity patterns | No — must be explicitly enabled | A sudden spike in TerminateInstances calls |
Management Events are visible in the console as Event History for 90 days — no Trail required, no charge. But after 90 days they vanish. For long-term retention and cross-account analysis, you need a Trail that writes to S3.
Data Events are enabled selectively at the resource level — per S3 bucket, per Lambda function, per DynamoDB table. If S3 Data Events are not enabled, GetObject and PutObject are simply not recorded. In high-traffic environments the log volume can explode, so weigh the cost trade-off carefully.
Insights Events use the prior seven days of Management Events as a baseline and automatically surface anomalous API activity. If a call that averaged 10 times per day suddenly fires thousands of times, an Insights Event is generated. This is useful for early detection of insider threats or compromised credentials.
Event History vs Trail: Event History is free but limited to 90 days and a single region. A Trail supports long-term S3 retention, Athena-based analysis, and — with the Multi-Region option — funnels events from every region into a single bucket.
!CloudTrail's 3 event types
Trail Design: Multi-Region, Org-wide, and Tamper-proof Patterns
Every Trail design requires three decisions.
Multi-Region Trail: enabling "Apply trail to all regions" funnels events from every AWS region into a single S3 bucket. Global service events — IAM, STS, CloudFront — require the additional "Include global service events" toggle.
Org-wide Trail: created from an AWS Organizations management account, it automatically covers every member account without any per-account configuration.
Tamper-proof stack: this is where the exam focuses heavily.
| Protection Mechanism | Role | |----------------------|------| | Log File Integrity Validation | Generates an hourly Digest file (SHA-256 + RSA signature) — validate with | | S3 Object Lock Compliance mode | No one — including root — can delete or overwrite logs during the retention period. Think of it as a notarized safe-deposit box. | | S3 Object Lock Governance mode | Only users with the permission can override retention | | S3 MFA Delete | Requires MFA authentication before a versioned object can be deleted | | Cross-Account Log Archive | The source account has PutObject only — it cannot delete its own logs | | KMS SSE-KMS | Protects log confidentiality; key policy controls who can decrypt |
The Log Archive Account pattern is fundamentally about account isolation. A dedicated Log Archive account hosts the S3 bucket that receives logs from every member account. Member accounts are granted PutObject on that bucket only — they cannot delete or overwrite. If an operational account is compromised, the attacker cannot reach the logs.
---
AWS Config: Configuration Change Tracking and Compliance Automation
Imagine AWS Config as a room-layout logbook. It records where the sofa was, who moved it, when the move happened, and whether the sofa is currently in the position required by policy.
A Configuration Item (CI) is a point-in-time snapshot of a resource: its type, all attribute values, relationships to other resources, and the timestamp of the change. Every time a resource is modified, a new CI is created — so you get a browsable timeline of every configuration state the resource has ever been in. The Configuration Recorder is the engine that automatically tracks supported resource types; one Recorder must be created per region.
Config Aggregator collects Config data from multiple accounts and multiple regions into a single aggregation account, giving security and compliance teams a unified view without having to log into each account.
Config Rules evaluate whether resource configurations satisfy policy:
Managed Rules: AWS provides over 150 pre-built rules — , , and many others. Custom Rules: backed by a Lambda function, these encode organization-specific policies that AWS Managed Rules do not cover. Conformance Pack: a curated bundle of Config Rules mapped to a regulatory framework — PCI-DSS, HIPAA, NIST 800-53 — deployed as a single unit.
Remediation Actions link a non-compliant resource to a Systems Manager Automation document and can automatically correct the violation without human intervention.
| Question | Service That Answers It | |----------|-------------------------| | Who changed this resource? | CloudTrail (API caller, UserAgent, source IP) | | When and how was this resource changed? | Config (CI timeline) | | Is this resource currently compliant with policy? | Config Rules |
---
CloudWatch Logs and EventBridge for Real-Time Alerting and Automation
When CloudTrail writes only to S3, there is a delivery delay of up to 15 minutes — far too slow for real-time response. Two paths close that gap.
The CloudWatch Logs path: enable "Send to CloudWatch Logs" on a Trail and events are delivered to a log group in near real-time. A Metric Filter scans the stream for a specific pattern, increments a metric, and triggers a CloudWatch Alarm that sends an SNS notification. For example, the pattern detects console login failures. A Subscription Filter forwards the entire log stream — in real time — to Kinesis Data Firehose, Kinesis Data Streams, or Lambda for further processing.
The EventBridge path: EventBridge is the air-raid siren — it fires within seconds of the API call, before the log even reaches S3. You can route events directly to Lambda, SNS, SQS, Step Functions, and more, all without configuring the CloudWatch Logs forwarding pipeline.
Exam decision guide: for real-time API change detection, CloudTrail + EventBridge is the correct answer. Config Rules finish evaluating several minutes after the configuration change and produce no new alert if the compliance state was already non-compliant. CloudWatch Logs Metric Filter requires the additional Trail-to-CWL forwarding setup and carries that latency.
CloudWatch Logs Insights provides SQL-like interactive log queries. Saved queries can be pinned to dashboards or scheduled to run on a recurring basis.
---
Centralized Log Aggregation Architecture: Log Archive Account, Firehose, OpenSearch, and Athena
When dozens or hundreds of accounts each accumulate their own logs, achieving a unified view becomes impractical without a deliberate architecture. The Log Archive Account pattern is the standard solution. A dedicated account hosts the S3 bucket that receives logs from every member account; member accounts hold PutObject rights only. Pairing S3 Object Lock (Compliance mode) with an Org-wide Trail means that even if an operational account is fully compromised, the attacker cannot touch the logs.
For real-time streaming aggregation, Kinesis Data Firehose is the backbone. The flow runs: CloudWatch Logs Subscription Filter → Kinesis Data Firehose → central S3 bucket or OpenSearch cluster. On OpenSearch you can build Kibana dashboards that visualize security events as they arrive and trigger alerts when thresholds are breached.
For high-volume post-incident analysis, Athena is the right tool. Create an Athena table over the CloudTrail logs or VPC Flow Logs in S3 and query them with standard SQL — no servers, no infrastructure, and cost-effective for intermittent workloads.
VPC Fl