These two services are consistently confused in interviews and in practice. The distinction is fundamental: CloudTrail records actions (API calls); AWS Config records state (resource configurations).
AWS CloudTrail: The "Who Did What"
CloudTrail is an API call audit log. Every time any principal (user, role, service) makes an API call to AWS — creating an instance, deleting a bucket, changing a security group — CloudTrail records it.
What a CloudTrail event contains:
- Who: The IAM identity (user ARN, role ARN, access key ID)
- What: The API action (AuthorizeSecurityGroupIngress, DeleteBucket, etc.)
- When: Timestamp (UTC)
- Where from: Source IP address
- On what: The resource ARN
Questions CloudTrail answers:
- "Who terminated this instance at 3 AM?"
- "What IP address was used to access our account before the breach?"
- "Did anyone access this S3 bucket in the last 30 days?"
Key Feature: Log File Integrity Validation
This is a critical security feature that is frequently tested in interviews and certifications.
CloudTrail delivers log files to S3 every 5 minutes. When you enable Log File Integrity Validation, CloudTrail also delivers an hourly Digest File. The digest file contains:
- The SHA-256 hash of each log file delivered in the past hour.
- The hash of the previous digest file.
- A digital signature using a private key held by AWS.
This creates a cryptographic chain. If an attacker (or a rogue admin) modifies or deletes a log file to cover their tracks, the hash stored in the digest file will no longer match the modified file. The chain breaks.
AWS provides a single validation call, scoped to a trail ARN and a time range, that walks this hash chain and reports the specific file and the nature of the integrity failure if any log has been tampered with.
AWS Config: The "What Does It Look Like Now (and Before)"
AWS Config is a configuration history and compliance engine. It continuously records the configuration state of your AWS resources and evaluates them against rules you define.
Questions AWS Config answers:
- "What did this Security Group's inbound rules look like last Tuesday at 2 PM?"
- "How many EC2 instances in our account are not using encrypted EBS volumes?"
- "Which S3 buckets have public access enabled right now?"
Config Rules are the compliance engine. AWS provides hundreds of managed rules (pre-built checks), and you can write custom rules using Lambda.
| Managed Rule | What It Checks |
|---|---|
s3-bucket-public-read-prohibited |
No S3 bucket allows public read access |
encrypted-volumes |
All EBS volumes are encrypted |
restricted-ssh |
No Security Group allows unrestricted port 22 inbound |
root-account-mfa-enabled |
Root account has MFA enabled |
Auto-Remediation is where Config becomes truly powerful. When a rule marks a resource as Non-Compliant, you can attach a Remediation Action — an SSM Automation document that runs automatically to fix the violation.
Example flow:
1. Developer creates an S3 bucket with public read access.
2. Config rule s3-bucket-public-read-prohibited evaluates the bucket → Non-Compliant.
3. Auto-remediation triggers SSM Automation document AWS-DisableS3BucketPublicReadWrite.
4. The bucket's public access is removed — automatically, within minutes, without human intervention.
A common interview question: "How would you prevent developers from creating public S3 buckets?" There are multiple valid answers at different layers: (1) Preventive — Use an SCP (Service Control Policy) in AWS Organizations to deny s3:PutBucketAcl with public grants entirely. (2) Detective + Corrective — Use an AWS Config rule with auto-remediation to detect and fix violations. (3) Account-level — Enable S3 Block Public Access at the account level. A strong answer mentions all three layers and explains that defense-in-depth means you don't rely on any single control.