If the Threat Detection domain is where the SCS-C02 exam asks “something is wrong — what do you do?”, the Security Logging and Monitoring domain is where it asks the question that comes first: “how would you even know something was wrong?” Detection services like GuardDuty are only as good as the telemetry feeding them, and that telemetry is exactly what this domain is about.
It’s also the single largest domain on the AWS Certified Security - Specialty (SCS-C02) exam — roughly 18% of your score — so it deserves dedicated, hands-on preparation. This deep dive is written from a practitioner’s perspective. We’ll cover the four logging and monitoring services the exam expects you to know cold — CloudTrail, CloudWatch, AWS Config, and VPC Flow Logs — plus how to query all of it with Athena, and how to wire it together into the centralized logging architecture the exam loves to test.
If you need the full exam picture first, start with the AWS Security Specialty Exam Guide 2026 and the domains breakdown, then come back here to go deep on logging and monitoring.
Where this domain sits on the SCS-C02 exam
The SCS-C02 exam is organized into six domains. Logging and monitoring is the foundation the others stand on:
| Domain | Weight | What it covers |
|---|---|---|
| Threat Detection & Incident Response | ~14% | GuardDuty, Security Hub, Detective (deep dive) |
| Security Logging & Monitoring | ~18% | CloudTrail, CloudWatch, Config, VPC Flow Logs, Athena |
| Infrastructure Security | ~20% | VPC, WAF, Shield, network controls |
| Identity & Access Management | ~16% | IAM, STS, Identity Center, policy evaluation |
| Data Protection | ~18% | Encryption, key management (KMS deep dive) |
| Management & Security Governance | ~14% | Organizations, Control Tower, multi-account |
The recurring theme: the exam wants you to choose the right logging source for a question and to know the precise distinctions between services that sound similar. Get those distinctions wrong and you’ll lose points across this entire third of the exam.
The mental model: three different questions
Before any service details, internalize this. CloudTrail, AWS Config, and VPC Flow Logs each answer a different question, and the exam is built around picking the right one:
| Service | Question it answers | Example |
|---|---|---|
| CloudTrail | Who did what, when, from where? | ”Who deleted this security group at 02:00?” |
| AWS Config | What does this resource look like, and how has it changed? | ”Was this S3 bucket ever public? When did encryption get disabled?” |
| VPC Flow Logs | What network traffic flowed in and out? | ”Did this compromised instance talk to an unknown IP?” |
| CloudWatch | Is a metric or log pattern crossing a threshold right now? | ”Alert me when root logs in or when 4xx errors spike.” |
When a scenario says “an auditor needs to prove who made an API call,” that’s CloudTrail. When it says “show whether a resource drifted from its compliant configuration,” that’s Config. When it says “investigate suspicious network connections,” that’s VPC Flow Logs. Train this reflex and a large chunk of the domain becomes automatic.
AWS CloudTrail — the API audit log
AWS CloudTrail records API activity across your account: every call made through the console, CLI, SDKs, and AWS services themselves. It is the authoritative answer to “who did what.”
The three event types
This is a guaranteed exam topic. Know the differences:
- Management events — control-plane operations like
RunInstances,CreateBucket,AttachRolePolicy. Logged by default and free for the first copy. - Data events — high-volume data-plane operations like S3
GetObject/PutObject, LambdaInvoke, and DynamoDB item activity. Not logged by default (volume and cost), so if a question says “track object-level access to a sensitive S3 bucket,” the answer is enable data events on a trail. - Insights events — automatically detect unusual patterns in write management events (e.g., a sudden burst of
Delete*calls). Must be explicitly enabled.
Default event history vs. a trail
A subtle but heavily tested distinction:
- Event history is the free, always-on 90-day view of management events in the console. It cannot be customized and does not cover data events.
- A trail is what you create to deliver events to an S3 bucket (and optionally CloudWatch Logs) for long-term retention, data events, and analysis. If a question requires retention beyond 90 days, custom analysis, or data events, the answer involves a trail — not event history.
Integrity, multi-account, and protecting the logs
The exam cares deeply about trustworthy logs:
- Log file integrity validation produces signed digest files so you can prove logs weren’t tampered with after delivery — critical for forensics and compliance.
- An organization trail (created from the management account) captures events from all member accounts into one place automatically — the standard answer for “centralize CloudTrail across the organization.”
- Protect the destination bucket with a restrictive bucket policy, SSE-KMS encryption, MFA Delete or S3 Object Lock, and ideally store it in a dedicated Log Archive account so even admins in workload accounts can’t quietly delete evidence.
# Create a multi-region trail that also feeds CloudWatch Logs
aws cloudtrail create-trail \
--name org-security-trail \
--s3-bucket-name my-central-cloudtrail-logs \
--is-multi-region-trail \
--kms-key-id alias/cloudtrail-logs-key
aws cloudtrail start-logging --name org-security-trail
# Enable S3 object-level (data) events for a sensitive bucket
aws cloudtrail put-event-selectors \
--trail-name org-security-trail \
--event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
"DataResources":[{"Type":"AWS::S3::Object",
"Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'Exam tip:
is-multi-region-trailis the right choice almost every time. Single-region trails miss activity in other regions — a classic gap attackers exploit by operating in an unused region.
CloudTrail Lake is worth knowing as the managed alternative: a queryable data lake where you run SQL directly against your events without standing up Athena, with retention up to several years. If a scenario emphasizes “run SQL on years of CloudTrail with minimal setup,” think CloudTrail Lake; if it emphasizes “query logs already in S3 alongside other log types,” think Athena.
Amazon CloudWatch — metrics, logs, and alarms
Where CloudTrail is the record, Amazon CloudWatch is the real-time monitoring and alerting layer. For SCS-C02, focus on three pieces.
CloudWatch Logs and metric filters
CloudWatch Logs collects logs from Lambda, VPC Flow Logs, CloudTrail, and EC2/on-prem hosts via the CloudWatch agent. The security superpower here is the metric filter: it scans incoming log events for a pattern, increments a custom metric when it matches, and lets you alarm on it.
This is the canonical exam pattern for “alert me when a specific security event happens.” For example, alert on root account usage:
aws logs put-metric-filter \
--log-group-name org-security-trail \
--filter-name RootAccountUsage \
--filter-pattern '{ $.userIdentity.type = "Root" }' \
--metric-transformations \
metricName=RootUsageCount,metricNamespace=Security,metricValue=1
aws cloudwatch put-metric-alarm \
--alarm-name root-account-used \
--metric-name RootUsageCount --namespace Security \
--statistic Sum --period 300 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:security-alertsThe flow — CloudTrail → CloudWatch Logs → metric filter → alarm → SNS — is one of the most testable architectures in the whole domain. The CIS AWS Foundations Benchmark is essentially a list of metric filters like this (root usage, unauthorized API calls, IAM policy changes, security group changes), and the exam draws heavily from it.
Logs Insights and subscription filters
- CloudWatch Logs Insights is an interactive query language for ad-hoc investigation across log groups — good for “quickly find all denied requests in the last hour.”
- Subscription filters stream matching log events in near real time to Kinesis Data Streams, Data Firehose, or Lambda — the answer when a scenario needs logs forwarded to a SIEM or a custom processing pipeline as they arrive.
Exam tip: Don’t confuse a metric filter (turns logs into a CloudWatch metric you can alarm on) with a subscription filter (streams the raw logs elsewhere). Different jobs, frequently swapped in distractor answers.
AWS Config — configuration state and compliance
AWS Config continuously records the configuration of your resources and how it changes over time. It is the answer to drift, history, and compliance questions.
| CloudTrail | AWS Config |
|---|---|
| Who made an API call and when | What state a resource is in and how it changed |
| Event/action centric | Resource/configuration centric |
| ”Who modified the bucket policy?" | "Is this bucket public, and was it ever?” |
This pairing — “who changed it” (CloudTrail) vs. “what it looks like now / its history” (Config) — is one of the most common single-question discriminators on the exam.
Config rules, remediation, and aggregation
- Config rules evaluate resources for compliance, using AWS managed rules (e.g.,
s3-bucket-public-read-prohibited,encrypted-volumes,iam-user-mfa-enabled) or custom rules backed by Lambda or CloudFormation Guard. - Remediation actions tie a rule to an SSM Automation document so non-compliant resources are fixed automatically — e.g., re-enabling S3 encryption the moment Config flags a bucket. This auto-remediation pattern shows up across multiple certs; for the deeper hands-on version, see the AWS incident response and auto-remediation guide.
- Conformance packs bundle many rules (and remediations) into a single deployable compliance template.
- An aggregator rolls up compliance data across multiple accounts and regions into one view — the standard answer for organization-wide compliance reporting.
# Turn on a managed rule that flags publicly readable S3 buckets
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "s3-no-public-read",
"Source": {"Owner": "AWS",
"SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"},
"Scope": {"ComplianceResourceTypes": ["AWS::S3::Bucket"]}
}'Exam tip: If a scenario wants automatic correction of misconfigurations, look for the answer that combines Config rule + SSM Automation remediation. If it only wants detection and reporting, the rule (or a conformance pack) alone is enough.
VPC Flow Logs — network forensics
VPC Flow Logs capture metadata about IP traffic to and from network interfaces — source/destination IPs and ports, protocol, packet/byte counts, and an ACCEPT/REJECT action. They do not capture packet payloads; for full packet capture the exam expects VPC Traffic Mirroring instead. Knowing that boundary is a frequent point.
Key facts the exam tests:
- Flow logs can be created at the VPC, subnet, or ENI level. A VPC-level log covers every interface within it.
- Destinations: CloudWatch Logs, S3, or Kinesis Data Firehose. Choose S3 + Athena for cheap, large-scale analysis; CloudWatch Logs for metric filters and alarms.
- Filter by ACCEPT, REJECT, or ALL. Investigating blocked traffic? Capture REJECT.
- Custom formats let you add fields like
pkt-srcaddr/pkt-dstaddr(the real source/dest behind a NAT) andtcp-flags.
A textbook scenario: an instance is suspected of exfiltration. VPC Flow Logs reveal the destination IPs and ports it contacted, while a REJECT pattern can expose port-scanning. (GuardDuty consumes this same telemetry automatically — see the threat detection deep dive.)
Amazon Athena — querying logs at scale
Once CloudTrail, VPC Flow Logs, and ALB/S3 access logs land in S3, Amazon Athena lets you run serverless SQL directly against them — no cluster to manage, pay per data scanned. It’s the exam’s default answer for “analyze large volumes of logs already stored in S3.”
-- Find every console/API call made by the root user, newest first
SELECT eventtime, eventsource, eventname, sourceipaddress
FROM cloudtrail_logs
WHERE useridentity.type = 'Root'
ORDER BY eventtime DESC
LIMIT 50;Practitioner detail the exam rewards: partition your data (by date/region) and use partition projection so queries scan less S3 and cost less. For an organization-wide, normalized view, Amazon Security Lake centralizes security logs from AWS and third parties into the OCSF schema in your account, queryable by Athena and partner tools — the right answer when a scenario stresses a standardized, multi-source security data lake.
Putting it together: centralized, tamper-resistant logging
The architecture the exam idealizes, especially for multi-account governance:
- A Log Archive account holds a central, KMS-encrypted S3 bucket with Object Lock and tight bucket policies — logs are write-once and admins in workload accounts can’t delete them.
- An organization CloudTrail delivers every account’s API activity there automatically.
- AWS Config (with an aggregator) and VPC Flow Logs ship to the same central account.
- Athena / Security Lake query the consolidated data; CloudWatch metric filters + alarms drive real-time alerting to SNS; GuardDuty and Security Hub sit on top for detection and posture.
This is the backbone behind AWS Control Tower’s “log archive” account, and recognizing it lets you eliminate wrong answers quickly. For multi-account governance more broadly, study it alongside the domains breakdown.
Quick-reference: which service for which scenario
| Scenario in the question | Correct service |
|---|---|
| Prove who deleted a resource | CloudTrail |
| Track S3 object-level reads/writes | CloudTrail data events |
| Detect when a bucket became public / drifted | AWS Config |
| Auto-fix a non-compliant resource | Config rule + SSM remediation |
| Investigate suspicious network connections | VPC Flow Logs |
| Full packet capture for deep inspection | VPC Traffic Mirroring |
| Alert in real time on root login | CloudWatch metric filter + alarm |
| Stream logs to a SIEM as they arrive | CloudWatch subscription filter → Firehose |
| Run SQL over years of logs in S3 | Athena (or CloudTrail Lake) |
| Standardized multi-source security data lake | Amazon Security Lake (OCSF) |
Frequently asked questions
Is CloudTrail enabled by default?
Management-event event history is on by default for the last 90 days and is free. But to retain logs longer, capture data events, validate integrity, or analyze them, you must create a trail that delivers to S3. The exam often hinges on this gap.
What’s the difference between CloudTrail and CloudWatch?
CloudTrail records API activity (who did what). CloudWatch handles metrics, logs, and alarms (real-time monitoring and alerting). They’re complementary: a very common pattern sends CloudTrail logs into CloudWatch Logs so you can metric-filter and alarm on them.
When do I use AWS Config instead of CloudTrail?
Use Config for resource state and change history (“is this resource compliant, and how has its configuration changed?”). Use CloudTrail for the API calls that caused those changes (“who made the change”). Compliance and drift questions are Config; “who did it” questions are CloudTrail.
Do VPC Flow Logs capture packet contents?
No — only traffic metadata (IPs, ports, protocol, bytes, ACCEPT/REJECT). For actual packet payloads, the exam answer is VPC Traffic Mirroring.
Athena or CloudTrail Lake for querying CloudTrail?
Use Athena when logs are already in S3 and you want to query them alongside other log types with full control over cost and partitioning. Use CloudTrail Lake when you want a managed, SQL-queryable store for CloudTrail (and Config) events with minimal setup and long retention.
How much of the exam is this domain?
Security Logging and Monitoring is roughly 18% — the largest single domain. Combined with Threat Detection (~14%), monitoring and response make up about a third of your score, so this material is well worth deep preparation. See the domains breakdown for the full weighting.
Conclusion and next steps
Logging and monitoring is the connective tissue of AWS security: CloudTrail tells you who, Config tells you what state, VPC Flow Logs tell you what flowed on the network, CloudWatch turns any of it into real-time alerts, and Athena lets you ask hard questions of all of it at scale. Master the distinctions in this guide and you’ll handle not just this domain but the detection, governance, and incident-response questions that depend on it.
The fastest way to convert this knowledge into exam-day reflexes is realistic practice. Sailor.sh’s AWS Certified Security - Specialty (SCS-C02) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty — including the logging, monitoring, and architecture scenarios covered here — with detailed explanations that surface the exact distinctions the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with structured study using the AWS Security Specialty study plan, review the full exam topics list, go deep on the related Threat Detection & Incident Response domain, and make sure Data Protection is solid — encryption of these very logs weaves through every other domain.