CloudTrail 與 AWS Config 稽核合規

Audit and compliance operations are core SysOps responsibilities, and on SOA-C02 they sit squarely inside Domain 1 (Monitoring, Logging, and Remediation). When a regulator, auditor, or security officer asks "who deleted the production S3 bucket at 02:14 UTC?" or "prove that every RDS instance had encryption-at-rest enabled continuously for the past 90 days", the SysOps engineer must produce evidence — and that evidence comes from exactly two services: AWS CloudTrail and AWS Config. CloudTrail answers who did what API call when; AWS Config answers what configuration the resource had at any point in time. Together they form the "two cameras of AWS audit" — one filming the API plane, one filming the resource plane — and almost every Domain 1.1 audit/compliance question on SOA-C02 hinges on knowing which camera to point at the scenario.

This guide covers CloudTrail and AWS Config from the SysOps angle: management events versus data events versus Insights events, single-region versus multi-region versus organization trails, log file integrity validation with SHA-256 digest files, forwarding API events to CloudWatch Logs for real-time alerting, AWS Config continuous configuration recording, the configuration timeline and resource relationships graph, AWS-managed Config rules versus custom Lambda-backed rules, conformance packs for CIS/NIST/PCI-DSS, multi-account multi-region aggregators, auto-remediation through Systems Manager Automation runbooks, and the recurring SOA-C02 patterns where CloudTrail detects the who and Config rules drive the fix. Where SAA-C03 tests which audit service belongs in the architecture, SOA-C02 tests how to configure the trail S3 bucket policy correctly, how to enable data events without exploding the bill, and how to wire a Config rule to an SSM Automation document with the right remediation IAM role.

Why Audit and Compliance Live Inside Domain 1 on SOA-C02

The official SOA-C02 Exam Guide v2.3 places CloudTrail and AWS Config under Task Statement 1.1 — "Implement metrics, alarms, and filters by using AWS monitoring and logging services" — alongside CloudWatch Metrics and CloudWatch Logs. The pairing is deliberate: CloudWatch is the monitoring surface for live operations, while CloudTrail and Config are the evidence surface for audit and post-incident review. Task Statement 4.1 then loops the same services back in for security troubleshooting ("Troubleshoot and audit access issues by using AWS services — for example, CloudTrail, IAM Access Analyzer, IAM policy simulator"), which means you should expect roughly 8 to 10 questions across the exam that touch CloudTrail, AWS Config, or both.

At the SysOps tier the framing is operational, not architectural. SAA-C03 asks "which service records who deleted an S3 object?" SOA-C02 asks "the S3 bucket was made public at 02:00 UTC; the CloudTrail trail is configured for management events only and the data event opt-in is off; can the SysOps team identify the API call that flipped the bucket policy?" The answer requires you to know that bucket policy changes are management events (recorded by default) while bucket object-level GET/PUT/DELETE calls are data events (opt-in only). The exam rewards candidates who can disentangle which event class belongs to which scenario, which retention applies, and which downstream pipeline (CloudWatch Logs Insights, Athena over S3, Security Hub, EventBridge) is the right tool for the question. CloudTrail and AWS Config also thread directly into Domain 3 (auto-remediation via Config rules → EventBridge → SSM Automation), Domain 4 (compliance guardrails enforced by Config rules and conformance packs), and Domain 5 (logging VPC and network changes), so mastery here pays dividends across the entire exam.

白話文解釋 CloudTrail and AWS Config

The mental boundary between CloudTrail and AWS Config is the single hardest distinction in Domain 1. Three analogies make the boundary stick.

Analogy 1: The Bank Branch — Security Cameras vs Vault Inventory

Picture a bank branch. CloudTrail is the security camera system at the front desk filming every customer interaction with a teller — every withdrawal request, every deposit slip, every account-opening form. The footage shows who approached the counter, what they asked for, when, and from which IP/source. AWS Config is the vault inventory ledger that records the contents of every safety deposit box at every point in time — not the transactions, but the state of each box right now and at every previous moment. If a deposit box is found empty, you check the camera (CloudTrail) to find who opened it; if you need to prove "this box has held diamonds continuously for the last 90 days for the insurance auditor", you check the inventory ledger (Config). The camera tells you about actions; the inventory tells you about states. Most real audits need both — first the inventory shows something is wrong, then the camera shows who did it.

Analogy 2: The Hospital — Doctor's Order Book vs Patient Chart

In a hospital, CloudTrail is the doctor's order book — every prescription written, every test ordered, every procedure approved, with the doctor's signature, time, and reason. AWS Config is the patient chart — the ongoing record of the patient's vital signs, diagnoses, medications currently administered, and allergy list at any point in time. If a patient suddenly gets the wrong medication (S3 bucket suddenly public), you read the order book (CloudTrail) to find which doctor wrote that order. If you need to prove "this patient was on antibiotics continuously from Day 1 to Day 14" (encryption was on continuously), you read the chart (Config). CloudTrail = orders/actions; Config = chart/states. Auto-remediation in Config is like a hospital protocol that automatically reverses an unsafe order the moment it appears on the chart — "if the chart ever shows penicillin for an allergy patient, automatically discontinue and page the attending".

Analogy 3: The Building Security System — Door Logs vs Floor Plan Snapshots

Think of an office building's security system. CloudTrail is the door access log — every keycard swipe, every door open/close, every elevator floor button press, attributed to a specific employee badge. AWS Config is the periodic floor-plan-with-tenants snapshot — every time someone moves a desk, repaints a wall, or removes a door, a new floor plan is filed in the building registry, and the registry keeps every previous version. Config rules are like building inspectors who walk the floor plan and flag violations — "every server room must have a locked door" (s3-bucket-public-read-prohibited); "no fire exit may be blocked" (vpc-default-security-group-closed). Conformance packs are like a CIS/NIST inspection bundle — a pre-built clipboard of 50 checks the inspector runs in one visit. Auto-remediation is like the building automatically locking a door the moment the inspector finds it unlocked — the SSM Automation document is the locksmith dispatched automatically.

CloudTrail Event Types: Management, Data, and Insights

CloudTrail records three distinct event categories, and the SOA-C02 exam tests the boundaries between them constantly.

Management events — the control plane

A management event is an API call that affects AWS resource configuration: RunInstances, CreateBucket, PutBucketPolicy, AttachRolePolicy, DeleteVolume, UpdateFunctionConfiguration, CreateUser, ConsoleLogin, AssumeRole. Management events are:

• Recorded for free by every trail (read events and write events can be toggled separately).
• Visible in CloudTrail Event History for 90 days even without an explicit trail — this is the always-on default surface in the console.
• The default for any new trail.

The 90-day Event History is searchable in the console for free, but it covers only the current account, the current region, and only management events. For cross-account, cross-region, or longer retention, you need a trail delivering to S3.

Data events — the data plane

A data event is a high-volume, data-plane API call: S3 GetObject / PutObject / DeleteObject, Lambda Invoke, DynamoDB item-level read/write, EBS direct API access. Data events are:

• Off by default on every trail — you must explicitly opt in per resource type.
• Billed per event at a small per-event rate. A heavily used S3 bucket can produce hundreds of millions of GET requests per day; data events for that bucket can dwarf the rest of your CloudTrail bill.
• Selectable with advanced event selectors to scope by ARN prefix, event name, or readOnly attribute — for example, "log only S3 PutObject and DeleteObject for arn:aws:s3:::sensitive-bucket/*", excluding GETs.

Data events are essential for audit scenarios that ask who read or wrote a specific object — without data events the trail simply does not record those calls.

Insights events — anomaly detection on write APIs

CloudTrail Insights is a paid feature that continuously analyzes the rate of write management API calls and produces an Insights event when the rate departs from the learned baseline by more than a threshold. Examples:

• A sudden spike in AttachRolePolicy calls — possible privilege escalation.
• A burst of RunInstances calls — possible cryptomining compromise.
• An anomalous drop in PutObject rate — possible application failure.

Insights events are recorded in their own folder in the destination S3 bucket and surface in the console under "CloudTrail Insights". They cost extra and are usually enabled only on management trails covering production accounts.

CloudTrail Trail Configuration: Single-Region, All-Region, and Organization Trails

CloudTrail offers three trail scopes, and the operational decision among them is recurring SOA-C02 territory.

Single-region trail

A single-region trail records events from one specific region only. It is rarely the right answer outside niche scenarios because:

• Global service events (IAM, STS, CloudFront, Route 53) are recorded only in us-east-1 and only by trails that are configured for the global services region.
• Most workloads span at least one region, and missing region coverage means missing audit trail.

All-region (multi-region) trail

An all-region trail is the operational default. One trail configuration covers every existing region and every newly-added region automatically. It captures global service events too. Per the SOA-C02 operational best practice:

• Always use all-region trails unless there is a specific compliance or cost reason not to.
• Enable log file integrity validation so tampering is detectable.
• Deliver to a dedicated, locked-down S3 bucket with a bucket policy that grants cloudtrail.amazonaws.com write access and denies deletion to everyone else.

Organization trail

An organization trail is created from the AWS Organizations management account or a delegated administrator account, and it automatically covers every member account in the organization — including future member accounts that join. Key properties:

• One trail captures every account, every region.
• Logs land in a single S3 bucket (typically in a dedicated logging account).
• Member accounts cannot disable, delete, or modify the organization trail — the management/delegated admin owns it.
• Member account administrators can still create their own trails locally if they need additional logging (organization trails do not preclude account-local trails).

This is the SOA-C02 sanctioned answer for any "centralized audit logging across all accounts" scenario. Trying to deploy and manage 200 individual account trails by hand is the wrong answer.

Trail destinations

A trail always delivers to S3. Optionally it can also deliver to:

• CloudWatch Logs — for real-time alerting via metric filters and Logs Insights queries.
• Amazon EventBridge — every CloudTrail event automatically appears as an aws.<service> event on the default event bus, regardless of trail configuration. Event delivery to EventBridge is essentially free and instantaneous.

Log File Integrity Validation: Digest Files and SHA-256 Hashing

A trail without integrity validation is a trail an attacker can tamper with — delete log files, edit them, or replace them. Log file integrity validation is CloudTrail's built-in tamper-evidence feature.

How it works

When integrity validation is enabled, CloudTrail every hour generates a digest file containing:

• The SHA-256 hash of every log file delivered in the previous hour.
• The SHA-256 hash of the previous digest file, forming a hash chain.
• A signature using a CloudTrail-owned RSA private key; the corresponding public key is fetched from the CloudTrail public key endpoint for verification.

Digest files land in a sibling folder in the S3 bucket (AWSLogs/<account>/CloudTrail-Digest/<region>/...).

Validating logs

The AWS CLI command aws cloudtrail validate-logs --trail-arn ... --start-time ... --end-time ... walks the digest chain, recomputes hashes, and reports any of:

• A log file that is missing.
• A log file whose hash does not match the recorded hash (modification).
• A digest file that has been deleted (gap in the chain).
• A signature that does not match the CloudTrail public key (forgery).

Any of those findings is grounds for an incident response — the integrity guarantee has been broken.

CloudTrail to CloudWatch Logs: Real-Time Alerting on API Events

CloudTrail's S3 destination is for archival and forensic search. For real-time alerting on critical API events, the trail must also deliver to CloudWatch Logs. The pattern is the SOA-C02-sanctioned approach for "alert when root user logs in" or "alert when a security group is modified to 0.0.0.0/0".

Configuration

In the trail settings, enable CloudWatch Logs delivery and pick or create a log group. CloudTrail creates an IAM role (CloudTrail_CloudWatchLogs_Role) with permissions to logs:CreateLogStream and logs:PutLogEvents on the chosen log group.

Metric filters for high-value events

Once events are streaming into CloudWatch Logs, create metric filters that match the JSON pattern of high-value API events and increment a custom CloudWatch metric. Then alarm on that metric.

Examples:

• Root account console login: filter pattern { ($.userIdentity.type = "Root") && ($.eventName = "ConsoleLogin") } → increment metric RootLoginCount → alarm at threshold ≥ 1.
• Security group modification: filter pattern { ($.eventSource = "ec2.amazonaws.com") && ($.eventName = "AuthorizeSecurityGroupIngress") } → metric → alarm.
• CloudTrail trail disabled: filter pattern matching StopLogging or DeleteTrail → metric → alarm — page the security team immediately because someone is trying to go dark.
• IAM policy changes: AttachUserPolicy, PutUserPolicy, CreatePolicy, etc.

Alternative: EventBridge rules

Equivalently — and more flexibly — you can match the same JSON pattern with an EventBridge rule on the default event bus and route directly to SNS, Lambda, or SSM Automation. EventBridge is increasingly the SOA-C02-preferred path because it composes with downstream automation and supports cross-account event buses for centralized security operations.

CloudTrail Lake — Queryable Event Store

CloudTrail Lake is a managed, queryable event store that stores CloudTrail events for up to 7 years (default 7 years; configurable from 7 days to 3,650 days / 10 years on extendable retention) and exposes a SQL query interface. It is an alternative to "trail to S3 + Athena over the bucket" for compliance teams that want a turn-key audit query surface.

Key operational properties:

• Event data store is the configuration unit; can be account-scoped or organization-scoped.
• SQL query language familiar to anyone who has used Athena.
• Federated query lets you query event data alongside other AWS data sources.
• Pricing is per-GB ingested; storage is included in the ingestion price for the default 7-year window, with extendable retention billed separately.

For SOA-C02 the typical scenario is "the auditor needs a SQL surface to investigate API calls back five years" — CloudTrail Lake is the answer. For "ship logs to a low-cost S3 archive and query occasionally with Athena", a regular trail with lifecycle policy is the answer.

AWS Config: Continuous Configuration Recording

AWS Config continuously records the configuration of supported AWS resources in your account and stores a history of every change. It is the resource state counterpart to CloudTrail's API actions.

What Config records

For every supported resource type (S3 buckets, EC2 instances, security groups, IAM roles, RDS instances, VPCs, hundreds more), Config produces a configuration item (CI) every time the resource changes. A CI captures:

• Resource metadata — ARN, type, region, account, creation time, tags.
• Configuration — the JSON describing the current state (encryption settings, public access block, security group rules, etc.).
• Relationships — links to other resources (a security group's CI references the VPC and the ENIs that use it).
• Related events — the CloudTrail event IDs that triggered the change.
• Compliance state — for each Config rule that evaluated this resource, COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA.

Configuration timeline

In the Config console, every resource has a configuration timeline — a chronological visualization of every CI. Click any point to see the full configuration at that time, the diff from the previous CI, and the linked CloudTrail event(s). This is the SOA-C02 answer for "show me what the resource looked like 30 days ago" or "produce evidence that encryption was continuously enabled".

Resource relationships graph

The configuration item also captures relationships: an EC2 instance CI links to its security groups, subnets, EBS volumes, IAM instance profile, and ENIs; an RDS DB instance CI links to its DB subnet group, security groups, parameter group, and option group. The relationships are queryable in the console and via the Config Advanced Query SQL surface, which lets you write queries like "list all EC2 instances using security group sg-xxx" or "find every resource in subnet-yyy".

Recording configuration

Config recording is opt-in per region: you create a configuration recorder that specifies which resource types to record and where to deliver snapshots. The recorder writes:

• Configuration history files to S3 every 6 hours (or configurable cadence).
• Configuration snapshots on demand or on a schedule.
• Configuration change notifications to SNS or to the configuration item stream consumed by Config rules.

Config supports all supported resource types (default) or a selective list when cost is a concern. Recording all resources is the SOA-C02 default for compliance posture; selective recording is used in cost-optimization scenarios where only a few resource types matter.

Config Rules: AWS-Managed vs Custom Lambda-Backed

A Config rule is the unit of evaluation that produces compliance state. Config evaluates rules either when a configuration item changes (configuration-change-triggered rules) or on a schedule (periodic rules), and writes COMPLIANT / NON_COMPLIANT back to the resource's CI.

AWS-managed rules

AWS publishes hundreds of managed rules covering common compliance checks. Examples that appear directly on SOA-C02:

• s3-bucket-public-read-prohibited — fail if any S3 bucket allows public read.
• s3-bucket-public-write-prohibited — fail if any S3 bucket allows public write.
• s3-bucket-server-side-encryption-enabled — fail if SSE not configured.
• encrypted-volumes — fail if any EBS volume is unencrypted.
• rds-storage-encrypted — fail if any RDS DB instance lacks encryption.
• ec2-instance-no-public-ip — fail if any EC2 instance has a public IP.
• restricted-ssh — fail if any security group allows 0.0.0.0/0 on port 22.
• iam-password-policy — fail if account password policy does not meet criteria.
• cloudtrail-enabled — fail if no CloudTrail trail is logging.
• vpc-flow-logs-enabled — fail if any VPC lacks flow logs.

Each managed rule has parameters you can tune (e.g., iam-password-policy accepts MinimumPasswordLength, RequireUppercaseCharacters, etc.).

Custom rules — Lambda-backed

When no managed rule fits, write a custom rule as an AWS Lambda function. Config invokes the Lambda with the configuration item; the Lambda inspects it and returns COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE. Custom rules are the answer when the compliance check is organization-specific (e.g., "every EC2 instance must have a CostCenter tag drawn from the approved finance list").

Custom rules — CloudFormation Guard

A newer alternative is CloudFormation Guard policy-as-code rules — declarative DSL for compliance checks. Less flexible than Lambda but no code to maintain.

Rule trigger types

Two trigger modes:

• Configuration changes — rule evaluates whenever a relevant CI changes. Best for "must-be-true-at-all-times" checks.
• Periodic — rule evaluates every 1, 3, 6, 12, or 24 hours regardless of CI changes. Best for checks that look at multiple resources together (e.g., "at least one CloudTrail trail must exist") or that need to catch slow drift.

Some managed rules support both modes; some support only one. Picking the wrong trigger type is a common SOA-C02 trap.

Conformance Packs: Pre-Built Compliance Bundles

A conformance pack is a packaged collection of Config rules and remediation actions, defined as a YAML template, deployable as a unit across one account or an entire organization with a single API call.

Sample packs AWS provides

AWS publishes conformance packs aligned to common frameworks:

• CIS AWS Foundations Benchmark v1.2 / v1.3 / v1.4
• NIST 800-53 rev 4 / rev 5
• PCI DSS v3.2.1
• HIPAA Security
• AWS Operational Best Practices for Amazon S3 / EC2 / RDS / IAM etc.
• SOC 2, FedRAMP Moderate, ISO 27001

Each pack is YAML; you can deploy as-is, fork to remove rules that do not apply, or extend with custom rules.

Deployment scopes

• Single account, single region: standard conformance pack.
• Organization-wide: organization conformance pack, deployed from the management account or a delegated admin; automatically covers existing and new member accounts.

Outputs

A conformance pack exposes a compliance dashboard in the Config console showing, per pack, the percentage of resources compliant, the failing rules, and the offending resources. Compliance officers love it because one screen replaces thirty Config rule status pages.

AWS Config Auto-Remediation with SSM Automation

The Config control plane is detection. Auto-remediation is the action that closes the loop — when a resource is found NON_COMPLIANT, an SSM Automation document runs to bring it back to compliance.

Configuration mechanics

Each Config rule can have a remediation action attached. The action specifies:

• SSM Automation document — AWS-managed (e.g., AWS-DisablePublicAccessForS3Bucket) or custom (your own document).
• Parameters — usually the resource ID is auto-injected; other parameters can be hardcoded or pulled from the rule.
• IAM role — the automation assumes role, which must have the permissions needed to call the corrective API. This role is the most common silent-failure point — without s3:PutBucketPolicy (or whatever the document needs) the remediation fails and the resource stays non-compliant.
• Mode — Automatic (executes immediately on NON_COMPLIANT) or Manual (operator clicks "Remediate" in the console).
• Maximum attempts and retry intervals — bounded retry behavior.

Common AWS-managed remediation documents

• AWS-DisablePublicAccessForS3Bucket — pairs with s3-bucket-public-read-prohibited.
• AWS-EnableS3BucketEncryption — pairs with s3-bucket-server-side-encryption-enabled.
• AWS-DetachVPCInternetGateway — pairs with VPC isolation rules.
• AWS-EnableCloudTrail — pairs with cloudtrail-enabled.
• AWS-AddTagsToResource — pairs with custom tag-policy rules.

When auto-remediation is wrong

Auto-remediation is dangerous when the "non-compliant" state might be intentional. A s3-bucket-public-read-prohibited rule auto-remediating a bucket that is intentionally a public website would break production. The SOA-C02-correct posture: enable auto-remediation only for rules where compliance is unambiguous (encryption, tagging), and use Manual mode for rules where human review is needed (public access, security group rules).

Config Aggregator: Multi-Account, Multi-Region View

A Config aggregator is a separate Config feature that collects configuration and compliance data from multiple accounts and regions into a single view.

Aggregator types

• Organization aggregator: created in the management account or delegated admin; automatically pulls from every member account in selected regions. New accounts joining the organization are auto-included.
• Account aggregator: created in any account with a curated list of source accounts and source regions; each source account must authorize the aggregator account.

What an aggregator gives you

• Aggregated compliance dashboard — see all rules, all accounts, all regions in one view.
• Aggregated resource inventory — query every account and region with a single SQL Advanced Query.
• Aggregated conformance pack status — per-pack compliance percentage across the whole org.

Operational considerations

• The aggregator only reads — it cannot drive auto-remediation cross-account. Remediation must run in the source account where the resource lives.
• Aggregation incurs no additional Config charge — you pay for the underlying CIs in each source account.
• For cross-account auto-remediation, EventBridge cross-account event bus + SSM Automation in the resource account is the pattern; aggregator is for visibility only.

Config vs CloudTrail: The Boundary You Must Memorize

This boundary is the single most-asked SOA-C02 audit/compliance differentiator.

The mental shortcut: API actions (verbs) → CloudTrail. Resource state (nouns) → Config. When the question mixes both ("the bucket was made public, who did it AND prove it stays private"), the answer is both — CloudTrail for the who, Config rule for the prove + auto-revert.

Scenario Pattern: S3 Bucket Was Made Public — Who Did It and How to Prevent Recurrence

This is the canonical SOA-C02 dual-service scenario. The runbook:

1. Find who did it (CloudTrail). The change to the bucket policy or ACL is a management event (PutBucketPolicy, PutBucketAcl, DeletePublicAccessBlock). It is recorded for free in the 90-day Event History or in the trail's S3 destination. Search by eventName = PutBucketPolicy and requestParameters.bucketName = sensitive-bucket. The userIdentity block names the IAM user, role, or assumed-role session that made the call. The sourceIPAddress, userAgent, and request parameters round out the forensic record.
2. Detect future occurrences proactively (Config rule). Deploy s3-bucket-public-read-prohibited (or s3-bucket-public-write-prohibited, or both). Configure the rule with configuration-changes trigger so the moment any bucket's public access state changes, Config evaluates.
3. Auto-revert (SSM Automation). Attach the AWS-managed AWS-DisablePublicAccessForS3Bucket document as the remediation action with Automatic mode. Provision the assume-role with s3:PutBucketPublicAccessBlock and s3:PutBucketPolicy permissions. The rule + document combination reverts a public bucket to private within minutes of the change.
4. Alert (EventBridge). Add an EventBridge rule on the Config Rules Compliance Change event for this rule with newEvaluationResult.complianceType = NON_COMPLIANT, targeting an SNS topic for the security team. Even with auto-remediation in place, the team should know it ran.
5. Pre-empt at scale (SCP). For accounts where no public buckets are ever legitimate, attach an SCP at the OU that denies s3:PutBucketPolicy and s3:PutBucketAcl actions when aws:RequestTag/Public is not "true" — preventing the change before it can happen, complementing detection and remediation.

The answer key is: CloudTrail for who, Config rule for detection, SSM Automation for remediation, EventBridge for notification, SCP for prevention — five services in one pipeline. Every SOA-C02 scenario in this family rewards candidates who can name and order all five.

Scenario Pattern: Compliance Team Needs Resource Configurations from 90 Days Ago

The compliance team asks "what was the configuration of every EC2 instance, security group, and S3 bucket on Feb 1 at 02:00 UTC?" CloudTrail is the wrong answer — CloudTrail records changes, not state.

The right answer:

1. Confirm Config recorder was on at the relevant time. If Config was not recording 90 days ago, the data simply does not exist — there is no retroactive recovery.
2. Use the configuration timeline in the Config console for each resource of interest, navigating to Feb 1 02:00 to see the exact configuration item.
3. For bulk extraction, use the configuration history files that Config delivered to S3 every 6 hours — they are partitioned by date and contain every CI from that window.
4. For SQL access, use Config Advanced Query for current state and an Athena table over the configuration history S3 bucket for historical state.

This pattern reinforces the boundary: state-at-time-T questions go to Config, action-at-time-T questions go to CloudTrail.

Scenario Pattern: Regulator Asks Who Deleted Bucket X

A regulator demands the identity of the user who deleted bucket customer-data-prod on March 15. The SysOps engineer must produce evidence.

1. Bucket deletion (DeleteBucket) is a management event — captured by every trail's default management event recording and by CloudTrail Event History for 90 days. No data event opt-in is needed.
2. Search CloudTrail Event History in the relevant region (S3 has a global service event behavior for some calls; check both the bucket's region and us-east-1).
3. The event record shows userIdentity.arn, the role/session if it was an assumed role, the source IP, MFA status, and timestamp. If the call was made via the console, the userAgent reflects the console URL.
4. If the deletion was more than 90 days ago, Event History is gone — only the trail's S3 destination has the record. This is why a long-retained organization trail in a dedicated logging account is the SOA-C02 standard.

Note the difference from "who deleted object X inside the bucket" — that is a data event (DeleteObject in S3 data events) and is only captured if data events were explicitly opted in on the trail. SOA-C02 frequently swaps "bucket" and "object" in these scenarios to test whether the candidate knows the management/data boundary.

Common Trap: CloudTrail Does NOT Record OS-Level Changes; Config Does NOT Record Application Output

A surprisingly common SOA-C02 confusion. The audit pair has limits:

• CloudTrail records AWS API calls only. It does not record:

  • OS-level commands run on EC2 (useradd, rm -rf, iptables rules).
  • Application-level events (a user logging into your web app).
  • CloudWatch agent metric publishes (those are API calls but they generate so much volume that CloudTrail does not record them by default — they are a special excluded category).
  • Network packet contents (use VPC Flow Logs).

• AWS Config records resource-level configuration only. It does not record:

  • File contents inside an EC2 instance.
  • Application code or data inside a Lambda function (only the function's metadata and runtime config).
  • Object-level state inside an S3 bucket (only the bucket's configuration).
  • Per-row state of a DynamoDB table.

For OS-level audit you need CloudWatch Logs (with the agent) plus Systems Manager Inventory. For application-level audit you need application logs to CloudWatch Logs plus CloudTrail data events if API access is part of the picture. The exam tests this boundary by offering "CloudTrail to record SSH login attempts on an EC2 instance" — wrong, that is auth.log shipped via CloudWatch agent. Or "AWS Config to detect that a file was modified inside an instance" — wrong, that is OS-level and outside Config's scope.

Common Trap: Data Events Cost — Opt-In Carefully

Data events are billed per event, and high-traffic S3 buckets or Lambda functions can generate millions per minute. A naive "enable data events on all S3 buckets" can multiply the CloudTrail bill. The SOA-C02 best practice:

• Use advanced event selectors to scope data events to specific resource ARNs.
• Limit to write-only data events (isReadOnly = false) when only mutations matter.
• Exclude internal service-to-service traffic (e.g., logging buckets that receive CloudTrail's own logs — recursive cost amplification).
• Test data event volume in non-prod before enabling in prod.

A common scenario: "the compliance team enabled S3 data events on every bucket including the CloudTrail logs bucket; the CloudTrail bill quintupled overnight". The answer is to scope data events with an advanced event selector excluding the logs bucket ARN.

Common Trap: Organization Trail vs Multiple Local Trails — Cost and Audit Posture

Organization trails are the SOA-C02 default for centralized audit. But three subtleties:

• The first copy of management events is free per trail. If both an organization trail and a local trail in a member account record the same events, you pay for the second copy (the local one).
• Organization trails cannot be modified or disabled by member accounts — that is a feature for security but a constraint for delegated audit teams.
• Member accounts can still create their own trails for operational purposes (for example, to deliver to a region-local CloudWatch Logs group for ChatOps). The organization trail handles compliance; the local trail handles operations. The exam-correct answer often uses both.

CloudTrail/Config in Security Hub and Aggregated Findings

AWS Security Hub is the aggregation surface for security findings across GuardDuty, Inspector, Macie, IAM Access Analyzer, and AWS Config. Config rule evaluations surface in Security Hub as findings, automatically scored against severity. Security Hub also runs its own checks aligned to standards (CIS AWS Foundations, AWS Foundational Security Best Practices, PCI-DSS) backed by Config rules under the hood.

For SOA-C02, the Security Hub angle is:

• One pane of glass for compliance posture across the whole organization.
• Findings flow to EventBridge (aws.securityhub event source), enabling auto-remediation pipelines on findings.
• Security Hub does not replace Config — it consumes Config rule results and Config rules are still the policy enforcement layer.
• Enabling Security Hub auto-enables a baseline set of Config rules; expect a Config bill bump.

SOA-C02 vs SAA-C03: The Operational Audit Lens

SAA-C03 and SOA-C02 both test CloudTrail and Config, but the lenses differ.

The SAA candidate selects the audit service; the SOA candidate configures it correctly, troubleshoots when it misbehaves, and operates the dashboard during compliance reviews.

Exam Signal: How to Recognize a CloudTrail/Config Question

CloudTrail/Config questions follow predictable shapes. Recognize them and your time on each question drops dramatically.

• "Who did X at time T?" — CloudTrail (Event History for ≤ 90 days, trail's S3 for older).
• "What did the resource look like at time T?" — AWS Config configuration timeline.
• "Was X continuously true for the past N days?" — AWS Config configuration history.
• "Detect non-compliance and revert" — Config rule + SSM Automation auto-remediation.
• "Centralize audit logs from all accounts" — Organization trail in management or delegated admin account.
• "Centralize compliance posture across all accounts" — Config organization aggregator + organization conformance pack.
• "Validate against CIS / NIST / PCI-DSS / HIPAA" — Config Conformance Pack matching the framework.
• "The S3 object was deleted but it is not in the trail" — data events were not enabled; opt in going forward.
• "Detect log tampering" — log file integrity validation enabled at trail creation; verify with aws cloudtrail validate-logs.
• "Real-time alert on a security-relevant API call" — trail to CloudWatch Logs + metric filter, or EventBridge rule on the aws.<service> event source.
• "SQL queries over years of audit data" — CloudTrail Lake.
• "Auto-remediation didn't run" — check the assume-role permissions on the SSM Automation document; alarm on Automation execution failures.

Decision Matrix — CloudTrail/Config Construct for Each SysOps Audit Goal

Use this lookup during the exam.

Common Traps Recap — CloudTrail and AWS Config

Every SOA-C02 attempt will see two or three of these distractors.

Trap 1: Trail captures S3 object operations by default

It does not — those are data events, opt-in only.

Trap 2: Event History covers older than 90 days

It does not — Event History is exactly 90 days. For older data, the trail's S3 destination is the source of truth.

Trap 3: Config aggregator can auto-remediate cross-account

It cannot — aggregators are read-only.

Trap 4: Detailed monitoring or CloudTrail captures memory/disk

It does not — those are CloudWatch agent metrics, separate ingestion path.

Trap 5: Log file integrity validation works retroactively

It does not — digest files are produced going forward only from when validation is enabled.

Trap 6: Config periodic rule with 24-hour cadence reverts in minutes

It does not — periodic rules evaluate at the configured interval. For minute-grain remediation use configuration-change-triggered rules.

Trap 7: SSM Automation runs without the right IAM role

It does not — the automation assume-role must have the API permissions the document calls. Missing permissions = silent failure.

Trap 8: Organization trail makes member-account local trails redundant

It does not — local trails complement organization trails for operational purposes (e.g., region-local CloudWatch Logs delivery for ChatOps).

Trap 9: CloudTrail records the agent's PutMetricData calls

It does not — high-volume telemetry calls like PutMetricData are excluded from CloudTrail.

Trap 10: Conformance packs replace SCPs

They do not — conformance packs detect; SCPs prevent. A complete posture uses both.

FAQ — CloudTrail and AWS Config

Q1: What is the precise difference between management events and data events on CloudTrail?

Management events record control-plane API calls — the calls that configure or manage AWS resources. Examples: RunInstances, CreateBucket, PutBucketPolicy, AttachRolePolicy, DeleteVolume, ConsoleLogin, AssumeRole. Trails record management events by default and the first copy is free. Data events record data-plane API calls — operations on the data inside resources. Examples: S3 GetObject / PutObject / DeleteObject (object-level operations on bucket contents, not the bucket itself), Lambda Invoke, DynamoDB item-level reads/writes. Data events are opt-in on each trail, billed per event, and selectable with advanced event selectors to scope by ARN, event name, or read/write attribute. The SOA-C02 trap is conflating bucket-level operations (management) with object-level operations (data) — PutBucketPolicy is a management event, PutObject is a data event, and only the first is captured by default.

Q2: How long does CloudTrail keep my data, and how do I prove continuous coverage for an audit?

Three storage tiers with three retentions: (a) CloudTrail Event History in the console — exactly 90 days of management events, free, current region only; (b) Trail logs in S3 — retained per your S3 lifecycle policy, which can be effectively forever; (c) CloudTrail Lake — up to 10 years with extendable retention, SQL-queryable. For continuous coverage proof in an audit, the standard pattern is an organization trail to S3 with versioning, MFA Delete, and integrity validation enabled at trail creation. Run aws cloudtrail validate-logs --trail-arn ... --start-time ... --end-time ... periodically (a SysOps Automation runbook on a maintenance window is a clean implementation) to verify the digest chain has no gaps.

Q3: When should I pick a custom Config rule over a managed rule, and what backs the custom rule?

Managed rules cover hundreds of common compliance checks, including encryption, public access, IAM password policy, security group rules, CloudTrail status, VPC Flow Logs, and most service-specific best practices. Use custom rules when no managed rule covers the policy — almost always organization-specific scenarios like "every EC2 instance must have a CostCenter tag from this approved list" or "every RDS instance must use a parameter group whose name starts with prod- if its environment tag is production". The backend is either AWS Lambda (full programmatic flexibility) or CloudFormation Guard (declarative DSL for policy-as-code). Lambda gives you the most flexibility but you maintain the code; Guard is lighter weight when the check expresses cleanly as a policy. SOA-C02 favors the managed rule when it covers the case and Lambda when not.

Q4: How do I make AWS Config auto-remediate a non-compliant resource without breaking production?

Wire the Config rule to an SSM Automation document via the rule's remediation action, set Automatic mode, and specify an assume-role with the exact permissions the document needs. Three operational guards prevent disasters: (a) scope the rule so it only evaluates resources you actually want auto-managed — use resource tags or the rule's resource ID parameter to exclude intentional exceptions (e.g., the public website bucket); (b) start in Manual mode for one to two weeks while you observe what the rule fires on, then promote to Automatic; (c) alarm on the SSM Automation execution events via EventBridge aws.ssm Automation Execution Status-Change Notification for status Failed so silent failures still page someone. Auto-remediation is dangerous in production without these guards because the rule will revert intentional changes — many SysOps teams have learned this the hard way after a Config rule reverted their disaster recovery test in the middle of the test.

Q5: How does an organization trail differ from a local trail, and which do I need for compliance?

A local trail is created in a single account and captures events from that account only. An organization trail is created from the AWS Organizations management or delegated admin account and automatically captures events from every member account in the organization (including new accounts that join later) into one S3 bucket. For compliance, the organization trail is the standard answer because: (a) it cannot be disabled or modified by member accounts, providing tamper resistance; (b) one trail covers every account, eliminating the chance of a member account skipping logging; (c) one S3 bucket holds all evidence, simplifying the auditor's evidence pull; (d) organization trails are immune to a member account being compromised — the attacker cannot turn off your audit. Member accounts may still create local trails for operational purposes (region-local CloudWatch Logs for ChatOps, account-specific data events) but the compliance trail is the organization trail. SOA-C02 favors organization trails for any "centralized audit across all accounts" scenario.

Q6: How does CloudTrail Lake differ from the standard "trail to S3 + Athena" pattern?

A standard trail to S3 delivers compressed JSON files to your bucket; querying them requires partitioning, Athena table creation, GlueCrawler maintenance, and SQL skill. A CloudTrail Lake event data store is a managed event store with a built-in SQL query interface, partitioned and indexed automatically, with retention up to 10 years and federated query support. CloudTrail Lake costs per-GB ingested but eliminates the operational overhead of maintaining Athena tables and partitions. Pick CloudTrail Lake when the compliance team wants a turn-key SQL surface and the data volume justifies the per-GB cost. Pick trail-to-S3-plus-Athena when you want the lowest possible storage cost (S3 standard / IA / Glacier lifecycle), are willing to maintain the Athena layer, and the query frequency is low.

Q7: What is the IAM permission gap that causes Config auto-remediation to silently fail?

The Config rule's remediation action specifies an assume-role ARN that SSM Automation assumes when running the document. The role's policy must permit (a) ssm:StartAutomationExecution and other SSM API calls implicitly granted via the SSM service role pattern, and crucially (b) the specific AWS API calls the document executes — for AWS-DisablePublicAccessForS3Bucket that means s3:PutBucketPublicAccessBlock and s3:GetBucketPublicAccessBlock on the target bucket. If the role lacks the corrective API permission, the document runs, the API call fails with AccessDenied, and the resource stays NON_COMPLIANT. There is no built-in alarm — silent failure is the default. SOA-C02 explicitly tests this scenario; the answer combines (a) the right role policy and (b) an EventBridge rule on aws.ssm Automation execution events with status Failed feeding SNS so you see remediation failures.

Q8: Why do I see "INSUFFICIENT_DATA" or "NOT_APPLICABLE" results on a Config rule?

INSUFFICIENT_DATA means Config has not yet been able to evaluate — typically because the configuration recorder is not capturing the relevant resource type, the rule was just created, or a Lambda-backed custom rule is timing out. Fix by checking the configuration recorder's resource type list (does it include the type the rule targets?), the rule's recent evaluation history, and the Lambda function's CloudWatch Logs. NOT_APPLICABLE means the rule deliberately decided this resource is out of scope — e.g., s3-bucket-public-read-prohibited against a non-S3 resource, or a custom Lambda that returned NOT_APPLICABLE for a resource that does not match the policy's intent. NOT_APPLICABLE is normal and expected; INSUFFICIENT_DATA is a configuration issue worth investigating.

Q9: How do I prove for an audit that an EBS volume was continuously encrypted for the past 12 months?

Three steps. (a) Verify AWS Config was recording the EBS resource type for the entire 12-month window — check the configuration recorder's history. If recording was off, the data does not exist. (b) Use the Config configuration timeline for the volume's resource ID; every CI captures the encrypted attribute. Walk the timeline from 12 months ago to today; every CI must show "encrypted": true. (c) For machine-readable evidence, query the configuration history files in S3 with Athena — SELECT configurationItemCaptureTime, configuration.encrypted FROM config_history WHERE resourceId = 'vol-xxx' ORDER BY configurationItemCaptureTime. Export the result CSV for the auditor. The Conformance Pack approach gives you the rollup percentage; the configuration history gives you the per-resource per-time evidence.

Q10: Should I use Config rules or SCPs to enforce a compliance policy?

Both, layered. SCPs are preventive — they deny the API call from being made in the first place. They live at AWS Organizations and apply to every IAM principal in the affected accounts. They are the right answer for hard rules like "no resources outside ap-southeast-1" or "no IAM user creation". Config rules are detective — they observe what was configured and flag violations. They can also drive corrective action via SSM Automation auto-remediation. The two layers complement each other: SCPs prevent the obvious bad change; Config rules detect the subtle drift that SCP cannot block (e.g., "every EBS volume must have a backup tag" — there is no API to deny since the volume creation API is legitimate, you just need the tag check). The SOA-C02 answer for a comprehensive policy is "SCP for prevention + Config rule for detection + auto-remediation for correction + EventBridge alert + organization conformance pack for the framework rollup". Picking only one layer is incomplete.

Further Reading and Related Operational Patterns

• AWS CloudTrail User Guide
• Logging Management and Data Events with CloudTrail
• Logging Insights Events with CloudTrail
• Creating and Updating a CloudTrail Trail
• Creating a CloudTrail Trail for an Organization
• Validating CloudTrail Log File Integrity
• Monitoring CloudTrail Log Files with CloudWatch Logs
• Viewing CloudTrail Event History
• What is AWS Config
• Evaluating Resources with AWS Config Rules
• AWS Config Conformance Packs
• Remediating Noncompliant Resources with AWS Config Rules
• Multi-Account Multi-Region Data Aggregation
• Viewing Configuration Timeline
• AWS Security Hub User Guide
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Once CloudTrail and Config are in place, the natural follow-on operational layers are: CloudWatch Logs and Logs Insights for application and system log analysis (the OS-level audit layer that CloudTrail and Config do not cover), EventBridge rules and SNS notifications as the routing fabric that connects Config rule findings and CloudTrail-detected anomalies to remediation pipelines, CloudWatch Metrics, Alarms, and Dashboards for operational situational awareness alongside compliance posture, and IAM Policies, MFA, SCPs, and Access Troubleshooting for the prevention layer that sits above Config's detection and SSM's correction.

• CloudWatch Metrics, Alarms, and Dashboards — SOA-C02 Study Notes
• CloudWatch Logs, Log Groups, and Logs Insights — SOA-C02 Study Notes
• EventBridge Rules, SNS, and Automated Remediation — SOA-C02 Study Notes
• IAM Policies, MFA, SCPs, and Access Troubleshooting — SOA-C02 Study Notes