Detection Day 2

SCS-C03 · Domain 1 · Detection (16%) · Day 2 of 4

Threat detection and automated assessments

On Day 1 you built CloudWatch metrics, alarms, EventBridge rules and health checks. Today AWS finds the problems for you: GuardDuty for threats and attack sequences, Security Hub and Security Hub CSPM for standards and correlation, Macie for sensitive data, Security Lake as the collection point, and AWS Config conformance packs and Systems Manager State Manager for checks that run on a schedule.

Skill 1.1.4 detect anomalous data and eventsSkill 1.1.5 automated assessments~90 min read + 30 min lab

Amazon GuardDuty: data sources and protection plans

Day 1 built alarms on metrics you chose yourself. Today the services find the bad thing for you. Skill 1.1.4 names four of them: GuardDuty, Security Hub, Macie and Security Lake. GuardDuty is the threat detector. It reads AWS logs in the background, compares them with threat intelligence and machine learning models, and creates a finding when something looks malicious, such as crypto mining, contact with a command-and-control server, or credentials used from an unusual place.

You turn GuardDuty on per account and per Region. It reads its foundational data sources straight from AWS. You do not need to enable CloudTrail, flow logs or DNS logging yourself, and it does not change your logs or cost you log storage.

Concept profile

Amazon GuardDuty

often confused with Amazon Inspector

?What is it?

A managed threat detection service. It continuously analyses AWS activity and workload behaviour and reports suspicious or malicious activity as findings with a severity of Low, Medium, High or Critical.

⚙How does it work?

Foundational data sources (always on): CloudTrail management events, VPC flow logs from EC2 instances, and DNS logs.
Protection plans add more data: S3 Protection (S3 data events), EKS Protection (EKS audit logs), Runtime Monitoring (an agent on EKS, ECS on Fargate and EC2), Malware Protection for EC2, Malware Protection for S3, RDS Protection, Lambda Protection, plus AI Protection and Malware Protection for AWS Backup.
Findings are sent to EventBridge in near real time (event source aws.guardduty), to Security Hub, to Detective, and can be exported to S3.
New accounts get a 30-day free trial that includes all protection plans except Runtime Monitoring.

{ }Structure

Foundational sources are always on; protection plans add more data; findings flow out to automation.

⇄GuardDuty vs Amazon Inspector

	GuardDuty	Amazon Inspector
Question it answers	“Is someone attacking us right now?”	“What known weaknesses do we have?”
Looks at	Logs and runtime behaviour	Software packages, CVEs, network reachability
Typical finding	CryptoCurrency:EC2/BitcoinTool.B!DNS	CVE in a package on an EC2 or ECR image
Needs an agent?	No (only Runtime Monitoring uses one)	Uses SSM Agent or agentless scans
Exam hint	“malicious”, “compromised”, “anomalous”	“vulnerability”, “CVE”, “patch”

!Common mistakes the exam tests

Thinking you must enable CloudTrail or VPC flow logs first: GuardDuty reads its own copy of the foundational sources.
Expecting GuardDuty to block traffic: it only detects. Blocking needs EventBridge plus Lambda, a security group change, WAF or Network Firewall.
Turning it on in one Region only: GuardDuty is Regional. Enable it in every Region, including ones you do not use, because attackers like unused Regions.
Using foundational detection to find threats inside containers: that needs Runtime Monitoring (or EKS Protection for the Kubernetes API).
Mixing up Malware Protection for EC2 (scans EBS volumes, agentless) with Malware Protection for S3 (scans new object uploads).

✓Benefits and use cases

Detect compromised EC2 instances and stolen credentials.
Detect data access anomalies in S3 and suspicious database logins.
Scan uploads in a file-sharing bucket for malware before anyone opens them.

Malware Protection: two different features

Malware Protection for EC2 scans the EBS volumes of an instance without an agent. A scan can start automatically when GuardDuty sees a suspicious finding on the instance (GuardDuty-initiated), or you can start one yourself (on-demand). Malware Protection for S3 scans each new object, or new version, uploaded to a bucket you choose. It can add a tag with the scan result to the object, so a bucket policy can block reads of untagged or infected objects. It can even be used without enabling GuardDuty, but then there is no detector and no GuardDuty finding: you read the results from EventBridge and CloudWatch instead.

Think of it like · a shopping mall’s security office

How a mall finds trouble without stopping every shopper.

AWS concept		Familiar thing
Foundational sources	≈	The CCTV cameras that are already in every corridor
Protection plans	≈	Extra cameras you pay to add in the stockroom, the car park and the lifts
Runtime Monitoring	≈	A guard standing inside the shop, watching what people do with their hands
Malware Protection for S3	≈	An X-ray machine at the delivery door that checks every new parcel
Finding	≈	The guard’s written incident report with a danger level
EventBridge	≈	The radio that sends the report to whoever must react

Real AWS example · a GuardDuty finding as it arrives in EventBridge

Shortened event for an EC2 instance talking to a known crypto-mining domain.

{
  "source": "aws.guardduty",
  "detail-type": "GuardDuty Finding",
  "detail": {
    "type": "CryptoCurrency:EC2/BitcoinTool.B!DNS",
    "severity": 8,
    "resource": { "resourceType": "Instance",
      "instanceDetails": { "instanceId": "i-0abc123example" } },
    "service": { "action": { "actionType": "DNS_REQUEST",
      "dnsRequestAction": { "domain": "pool.example-mining.com" } },
      "count": 14, "archived": false }
  }
}

An EventBridge rule matching source = aws.guardduty and detail.severity >= 7 can send this to SNS or start a Lambda function that isolates the instance.

Exam-style scenario

A company runs workloads on Amazon EKS and Amazon ECS on AWS Fargate. The security team must detect suspicious process execution and file access inside running containers, with the least operational effort. What should it do?

A. Enable GuardDuty and rely on the foundational data sources.
B. Enable GuardDuty Runtime Monitoring with automated agent management for EKS and ECS on Fargate.
C. Enable Amazon Inspector container image scanning.
D. Send container logs to CloudWatch Logs and write metric filters.

Show the worked answer

Answer: B

Runtime Monitoring uses a GuardDuty security agent that sees process execution, file access and network connections. With automated agent management GuardDuty installs and updates the agent for you.

Why not the others

A: Foundational sources see API calls, flow logs and DNS, not activity inside a container.
C: Inspector finds known vulnerabilities in images; it does not watch runtime behaviour.
D: High effort, and only detects what you write filters for.

How the exam tests this

“Detect malicious or anomalous activity with no agents”→ GuardDuty foundational sources.
“Suspicious behaviour inside containers or on EC2 hosts”→ Runtime Monitoring.
“Scan every new file uploaded to a bucket”→ Malware Protection for S3.
“Unusual logins to Aurora databases”→ RDS Protection.
“Detect threats in Kubernetes API activity”→ EKS Protection (audit logs).

Must remember

Foundational = CloudTrail mgmt + VPC flow + DNS, always on.
GuardDuty is Regional: enable everywhere.
GuardDuty detects; EventBridge + Lambda responds.
Runtime Monitoring = agent; Malware for EC2 = agentless EBS scans.
Malware for S3 can run without GuardDuty (no findings then).

Official sources: What is Amazon GuardDuty GuardDuty Runtime Monitoring Malware Protection for S3 GuardDuty findings and EventBridge

Attack sequences and managing GuardDuty at scale

One odd API call is often harmless. Ten odd steps in a row are an attack. GuardDuty Extended Threat Detection joins events across data sources, resources and time into one attack sequence finding. It is turned on automatically, at no additional cost, for every account that has GuardDuty.

In a real company you also need one team to see all accounts, hide known-good noise and teach GuardDuty about your own IP addresses. That is the job of the delegated administrator, suppression rules, and trusted and threat lists.

Concept profile

GuardDuty Extended Threat Detection

often confused with Single GuardDuty findings

?What is it?

A GuardDuty capability that detects multi-stage attacks in one account. When events that look harmless on their own appear in a suspicious order, GuardDuty creates an attack sequence finding with severity Critical.

⚙How does it work?

Looks for in-progress or recent attack behaviour within a 24-hour rolling window.
Attack sequence types: AttackSequence:IAM/CompromisedCredentials, AttackSequence:S3/CompromisedData, AttackSequence:EC2/CompromisedInstanceGroup, AttackSequence:EKS/CompromisedCluster, AttackSequence:ECS/CompromisedCluster.
Foundational sources are enough for the IAM sequence. More plans add coverage: S3 Protection for S3 data compromise, EKS Protection and Runtime Monitoring for EKS, Runtime Monitoring for ECS and EC2.
The finding lists each signal, the resources involved and the attack stages, so responders see the whole story at once.

{ }Structure

Signals become one Critical attack sequence; the administrator account manages findings for everyone.

⇄Extended Threat Detection vs Single GuardDuty findings

	Attack sequence	Single finding
Scope	Many signals, resources and time	One activity on one resource
Severity	Always Critical	Low, Medium or High
Cost	Included with GuardDuty	Included with GuardDuty
Best for	Prioritising a real, ongoing attack	Triage of individual events
Coverage depends on	Protection plans you enabled	Data sources you enabled

!Common mistakes the exam tests

Thinking Extended Threat Detection is a separate paid plan you must turn on: it is automatic and free with GuardDuty.
Expecting S3 data compromise sequences without S3 Protection.
Believing a suppression rule stops GuardDuty from creating findings: the findings are still created but archived.
Expecting a member account’s own trusted list to work: in a multi-account setup only the administrator manages lists and suppression rules.
Picking a different delegated administrator per Region: GuardDuty needs the same account in every Region.

✓Benefits and use cases

See a full credential-theft story as one Critical item instead of 20 alerts.
Central security account that sees findings from every account.
Quiet, known-good scanners (for example your own vulnerability scanner) without losing the audit trail.

Delegated admin, suppression rules and lists

With AWS Organizations, the management account designates a delegated GuardDuty administrator, usually a security tooling account (AWS advises against using the management account itself). It must be the same account in every Region, because GuardDuty is Regional. One administrator can manage up to 50,000 member accounts, and auto-enable can be set to NEW or ALL accounts. A suppression rule is a saved filter: matching findings are automatically archived, kept for 90 days, and not sent to EventBridge, Security Hub CSPM, S3 or Detective. A trusted list (one trusted IP list plus one trusted entity list per account per Region) means GuardDuty creates no findings for those entries; threat lists (up to six) make GuardDuty create findings when your resources talk to them. The newer entity lists can hold IP addresses and domains, and threat entity lists can also hold file hashes.

Think of it like · a school’s head of security

Watching many classrooms at once.

AWS concept		Familiar thing
Attack sequence	≈	Noticing that the same student was late, borrowed a key and was seen near the exam room: one story, not three notes
Delegated administrator	≈	The head of security who reads reports from every classroom
Suppression rule	≈	Filing the daily fire-drill reports straight into the archive drawer
Trusted list	≈	The list of parents who may enter without being reported
Threat list	≈	Photos of people who are banned from the grounds
Same admin in every Region	≈	One head of security for every campus, not a different one per building

Real AWS example · suppress findings from your own scanner

Archive port-scan findings that come from the company’s approved scanner instance.

$ aws guardduty create-filter --detector-id 12abc34d567e8fa901bc2d34eexample \
    --name approved-scanner --action ARCHIVE --rank 1 \
    --finding-criteria '{"Criterion": {
      "type": {"Eq": ["Recon:EC2/Portscan"]},
      "resource.instanceDetails.instanceId": {"Eq": ["i-0scanner0example"]}
    }}'
{ "Name": "approved-scanner" }

--action ARCHIVE makes this filter a suppression rule. Run it from the administrator account so it applies to members too.

Exam-style scenario

A company has 300 accounts in AWS Organizations. The security team wants GuardDuty enabled in all accounts and Regions, including accounts created in the future, and wants to manage findings from one account. The management account must not be used for daily security work. What should it do?

A. Enable GuardDuty in each account with a CloudFormation StackSet and send findings by email.
B. From the management account, designate a security tooling account as the delegated GuardDuty administrator in every Region and set auto-enable to ALL.
C. Make the management account the GuardDuty administrator and invite members by email.
D. Designate a different delegated administrator in each Region to spread the load.

Show the worked answer

Answer: B

The delegated administrator manages all members per Region, auto-enable covers new accounts, and the management account stays out of daily work.

Why not the others

A: No central view of findings, and new accounts need extra work.
C: AWS advises against using the management account, and invitations do not scale.
D: GuardDuty requires the same delegated administrator in every Region.

How the exam tests this

“Many low-level signals form one multi-stage attack”→ Extended Threat Detection attack sequence.
“Stop known-good findings from reaching the SIEM”→ Suppression rule (archives them).
“Never alert on our office IP range”→ Trusted IP / entity list.
“Alert when anything talks to these bad domains”→ Threat entity list.
“Manage GuardDuty for all accounts”→ Delegated administrator, same account in every Region.

Must remember

Attack sequences are Critical, free, 24-hour window.
S3 sequences need S3 Protection.
Suppressed = archived, not deleted, not forwarded.
Lists: 1 trusted IP + 1 trusted entity, up to 6 threat per account per Region.
Only the administrator manages lists and suppression rules.

Official sources: Extended Threat Detection Attack sequence finding types Managing accounts with AWS Organizations Suppression rules Entity lists and IP address lists

Security Hub and Security Hub CSPM

Older study material says “Security Hub” and means one product. That changed in 2025. AWS relaunched Security Hub as a unified risk and response service, and the original product is now called AWS Security Hub CSPM (cloud security posture management). Both live in the same console and user guide. The exam blueprint still says “Security Hub”, so read each question for what it needs.

If the question is about standards, control checks, ASFF, security scores or automation rules, it means the CSPM features. If it is about correlating signals into exposures, attack paths or OCSF findings, it means the new Security Hub.

Concept profile

AWS Security Hub CSPM

often confused with AWS Security Hub (2025)

?What is it?

The posture service: it checks your accounts against security standards using automated controls, gives a security score, and collects findings from AWS services and partners in the AWS Security Finding Format (ASFF).

⚙How does it work?

Standards: AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS, AWS Resource Tagging, AI Security Best Practices, and the service-managed AWS Control Tower standard.
Most controls run as AWS Config service-linked rules, so you must enable AWS Config and record resources.
Turn on consolidated control findings so one control creates one finding even when several standards include it.
Receives findings from GuardDuty, Inspector, Macie and others, but only findings created after it is enabled, and only in the Region where it is enabled.
New accounts get a 30-day free trial.

{ }Structure

CSPM checks posture; the relaunched Security Hub correlates everything into exposures.

⇄Security Hub CSPM vs AWS Security Hub (2025)

	Security Hub CSPM	Security Hub (2025)
Main job	Check posture against standards	Prioritise and respond to real risk
Finding format	ASFF	OCSF
Key output	Control findings, security score	Exposure findings, attack path graph
Inputs	Its own controls + GuardDuty, Inspector, Macie, partners	CSPM, GuardDuty, Inspector, Macie, IAM Access Analyzer
Exam hint	“CIS”, “FSBP”, “PCI DSS”, “controls”	“correlate”, “exposure”, “attack path”

!Common mistakes the exam tests

Enabling Security Hub CSPM without AWS Config recording: most controls then show no data.
Expecting findings from before enablement or from other Regions without cross-Region aggregation.
Enabling FSBP, CIS and NIST without consolidated control findings, then getting three findings for one problem.
Treating Security Hub as a detector of network threats: GuardDuty detects, Security Hub collects and prioritises.
Assuming the new Security Hub replaces CSPM: AWS recommends enabling both; CSPM findings feed the new service.

✓Benefits and use cases

Prove compliance with CIS or PCI DSS across all accounts.
One place to triage GuardDuty, Inspector and Macie findings.
Spot exposed resources that combine a misconfiguration with a vulnerability.

ASFF and OCSF

ASFF is the JSON format of Security Hub CSPM. Fields such as Severity.Label, Compliance.Status, Workflow.Status and RecordState are what automation rules and insights filter on. OCSF (Open Cybersecurity Schema Framework) is an open, vendor-neutral schema. The new Security Hub creates and receives findings in OCSF, and Amazon Security Lake also stores data in OCSF. If a question says “vendor-neutral schema” or “normalise data from many tools”, think OCSF.

Think of it like · a school report card and a head teacher

Two jobs that work together.

AWS concept		Familiar thing
Security Hub CSPM	≈	The report card that grades each class against the national curriculum
Standard (CIS, FSBP)	≈	The curriculum: a fixed list of things every class must do
Control	≈	One line on the report card, such as “homework handed in”
ASFF	≈	The school’s own report-card template
Security Hub (2025)	≈	The head teacher who joins the report card, the nurse’s notes and the guard’s reports to see which child really needs help today
OCSF	≈	A template that every school in the country can read

Real AWS example · a CSPM control finding (ASFF, shortened)

FSBP control S3.8 failed for one bucket.

{
  "SchemaVersion": "2018-10-08",
  "ProductArn": "arn:aws:securityhub:eu-west-1::product/aws/securityhub",
  "GeneratorId": "security-control/S3.8",
  "Title": "S3 general purpose buckets should block public access",
  "Severity": { "Label": "HIGH" },
  "Compliance": { "Status": "FAILED",
    "AssociatedStandards": [ { "StandardsId": "standards/aws-foundational-security-best-practices/v/1.0.0" } ] },
  "Resources": [ { "Type": "AwsS3Bucket", "Id": "arn:aws:s3:::finance-exports" } ],
  "Workflow": { "Status": "NEW" },
  "RecordState": "ACTIVE"
}

security-control/S3.8 appears because consolidated control findings is on: one finding, many standards.

Exam-style scenario

A security team enables Security Hub CSPM and the CIS AWS Foundations Benchmark in a new account. After a day, most controls show “No data”. GuardDuty findings appear normally. What is the most likely cause?

A. The CIS standard needs a paid subscription.
B. AWS Config is not enabled and recording resources in the account and Region.
C. GuardDuty must be disabled for CIS controls to run.
D. Security Hub CSPM controls only run once a week.

Show the worked answer

Answer: B

Most CSPM controls are AWS Config rules. Without Config recording, they have nothing to evaluate. GuardDuty findings do not depend on Config, so they still arrive.

Why not the others

A: Standards are part of Security Hub CSPM pricing, not a separate subscription.
C: GuardDuty and CSPM work together.
D: Controls run on resource changes and on periodic schedules.

How the exam tests this

“Check accounts against CIS or PCI DSS”→ Security Hub CSPM standards.
“Controls show no data”→ Enable AWS Config recording.
“One finding per control across standards”→ Consolidated control findings.
“Correlate a misconfiguration with a CVE into one exposure”→ Security Hub (2025) exposure findings.
“Vendor-neutral finding schema”→ OCSF.

Must remember

Old Security Hub = Security Hub CSPM now.
CSPM: standards, controls, ASFF, needs Config.
New Security Hub: exposures, attack paths, OCSF.
Standards: FSBP, CIS, NIST 800-53/171, PCI DSS.
AWS recommends enabling both.

Official sources: What are Security Hub and Security Hub CSPM? Introduction to AWS Security Hub What is Security Hub CSPM? Standards reference for Security Hub CSPM Exposure findings in Security Hub

Security Hub CSPM at scale: central configuration, aggregation and automation rules

Skill 1.1.5 asks for automations for regular assessments. In Security Hub CSPM, three features make the checks run everywhere and keep the noise down: central configuration decides which standards and controls are on in every account and Region, cross-Region aggregation brings all findings to one Region, and automation rules fix finding fields automatically as they arrive.

Concept profile

Central configuration (Security Hub CSPM)

often confused with Local configuration per account

?What is it?

A way for the delegated administrator to configure Security Hub CSPM for the whole organization from one place, using configuration policies applied to the root, OUs or accounts, in a home Region and its linked Regions.

⚙How does it work?

Integrate with AWS Organizations and designate a delegated administrator.
Pick a home Region (it is also the aggregation Region) and optional linked Regions. An opt-in Region can be linked but cannot be the home Region.
A configuration policy turns Security Hub CSPM on or off, enables standards, enables or disables controls, and can set control parameters. Up to 20 custom policies.
Policies are applied to a target or inherited from the closest parent; an applied policy beats inheritance. New accounts sit under the root until moved.
Centrally managed accounts cannot change their own settings; a target can be set to self-managed instead.

{ }Structure

Organization-wide settings on top; the per-finding automation flow below.

⇄Central configuration vs Local configuration per account

	Central configuration	Local configuration
Who configures	Delegated administrator only	Each account, in each Region
Regions	Home + linked Regions at once	One Region at a time
New accounts	Get the policy of their OU or root	Only auto-enable defaults
Control choice	Enable list or disable list per policy	Account by account
Exam hint	“consistent across all accounts and Regions”	Legacy, manual

!Common mistakes the exam tests

Using an enable list and expecting new controls to appear: with an enable list, all other controls, including new ones, stay disabled. A disable list turns new ones on.
Creating an automation rule in one Region and expecting it everywhere: automation rules are Regional.
Expecting automation rules to change old findings: they evaluate findings ingested or updated after the rule is created.
Forgetting rule order: when two rules change the same field, the rule with the highest RuleOrder number applies last and wins.
Thinking cross-Region aggregation costs extra: AWS says it does not add cost.

✓Benefits and use cases

Same standards and controls in hundreds of accounts.
One Region dashboard for every finding.
Raise severity for production, suppress findings on sandbox accounts.

Cross-Region aggregation and automation rules

Cross-Region aggregation replicates findings, insights, control compliance statuses and security scores from linked Regions into the home Region. Updates go both ways: if you change a finding’s workflow status in the home Region, the linked Region gets the change too. Automation rules are created only in the administrator account (up to 100 per administrator), apply to matching findings of all member accounts, and can change ASFF fields such as Severity, Workflow (for example SUPPRESSED), Note, Types and UserDefinedFields. For actions outside Security Hub, such as opening a ticket or isolating an instance, use an EventBridge rule on Security Hub Findings - Imported. The new Security Hub has its own automation rules that work on OCSF findings.

Think of it like · a chain of supermarkets

Running hundreds of shops the same way.

AWS concept		Familiar thing
Delegated administrator	≈	Head office
Configuration policy	≈	The rule book head office sends to each region of shops
Applied vs inherited	≈	A shop can get its own rule book; otherwise it uses its region’s book
Home Region aggregation	≈	All shops send their daily reports to head office
Automation rule	≈	An office clerk who stamps “low priority” on every report about the car-park lights before anyone reads it
EventBridge rule	≈	The clerk who phones the repair company when a fridge breaks

Real AWS example · an automation rule that suppresses findings in sandbox accounts

Rule created in the administrator account, in the home Region.

$ aws securityhub create-automation-rule --rule-name sandbox-low \
    --rule-order 10 --rule-status ENABLED \
    --description "Suppress low findings in sandbox" \
    --criteria '{"AwsAccountId":[{"Value":"444455556666","Comparison":"EQUALS"}],
                 "SeverityLabel":[{"Value":"LOW","Comparison":"EQUALS"}]}' \
    --actions '[{"Type":"FINDING_FIELDS_UPDATE",
      "FindingFieldsUpdate":{"Workflow":{"Status":"SUPPRESSED"},
        "Note":{"Text":"Sandbox: auto-suppressed","UpdatedBy":"automation"}}}]'
{ "RuleArn": "arn:aws:securityhub:eu-west-1:111122223333:automation-rule/a1b2c3d4-example" }

Repeat the rule in each Region you use, or deploy it with CloudFormation.

Exam-style scenario

A company uses Security Hub CSPM in 120 accounts and 4 Regions. It wants the same standards in every account, new accounts covered automatically, all findings visible in eu-west-1, and the newest controls enabled automatically when AWS releases them. What should it do?

A. Enable Security Hub CSPM in each account with a script and use an enable list of today’s controls.
B. Use central configuration with eu-west-1 as home Region and the other Regions linked, and a configuration policy on the root that uses a disable list.
C. Use automation rules to enable standards.
D. Use cross-Region aggregation alone.

Show the worked answer

Answer: B

Central configuration covers all accounts and linked Regions, the home Region aggregates findings, and a disable list keeps new controls enabled.

Why not the others

A: Manual, and an enable list keeps new controls disabled.
C: Automation rules change findings; they do not enable standards.
D: Aggregation moves findings but does not configure accounts.

How the exam tests this

“Same standards in all accounts and Regions”→ Central configuration policies.
“See all Regions’ findings in one place”→ Cross-Region aggregation (home Region).
“Automatically change severity or suppress findings”→ Automation rules (admin account, per Region).
“Open a Jira ticket for each critical finding”→ EventBridge rule (or Security Hub ticketing).
“New controls must turn on automatically”→ Policy with a disable list.

Must remember

Home Region = aggregation Region.
Applied policy beats inherited.
Enable list blocks new controls; disable list allows them.
Automation rules: admin only, per Region, max 100.
Highest RuleOrder applies last and wins.

Official sources: Central configuration in Security Hub CSPM Cross-Region aggregation Automation rules in Security Hub CSPM Automation rules in Security Hub

Macie findings and Security Lake as the collection point

Amazon Macie looks after data in S3. It creates two kinds of findings. A policy finding says a bucket’s settings got less secure, for example public access or encryption was turned off. A sensitive data finding says an object contains sensitive data such as credit card numbers, personal data or credentials. Skill 1.1.4 wants you to know how those findings reach automation.

Amazon Security Lake is not a detector. It is the place where all your security data lands in one format, OCSF. Day 3 covers it in depth; today you only need to know where it fits.

Concept profile

Macie finding publication

often confused with Macie findings in the console only

?What is it?

The settings that decide where Macie sends its findings: always to EventBridge, and optionally to Security Hub CSPM.

⚙How does it work?

EventBridge: Macie publishes both policy and sensitive data findings automatically.
New findings are published immediately. Updates to existing policy findings are published on a cycle, every 15 minutes by default (you can make it less often). Every sensitive data finding counts as new.
Security Hub CSPM: by default Macie publishes only policy findings. You can add sensitive data findings, or stop publishing.
Suppressed findings (archived by a Macie suppression rule) are not published to other services.
Sensitive data findings come from discovery jobs or automated sensitive data discovery.

{ }Structure

Where Macie findings go, and Security Lake as the place everything lands.

⇄Macie publishing vs Macie findings in the console only

	Macie	GuardDuty S3 Protection
Question it answers	“Is sensitive data exposed or at risk?”	“Is someone abusing S3 right now?”
Looks at	Bucket settings and object contents	S3 data events (API activity)
Typical finding	SensitiveData:S3Object/Financial	Exfiltration:S3/AnomalousBehavior
Reads object data?	Yes, it samples and inspects objects	No
Exam hint	“PII”, “credit card numbers”, “classify”	“unusual access”, “exfiltration”

!Common mistakes the exam tests

Expecting sensitive data findings in Security Hub CSPM by default: only policy findings are published there unless you change it.
Waiting for a bucket policy change to show immediately as an updated policy finding: updates follow the publication cycle.
Using Macie to find malware: that is GuardDuty Malware Protection for S3.
Thinking Security Lake detects threats: it stores and shares normalised data; detection happens in tools that read it.
Thinking Security Lake keeps data in an AWS-owned store: it writes to S3 buckets in your account.

✓Benefits and use cases

Alert the data owner when a bucket holding PII becomes public.
Send sensitive data findings to a ticket queue through EventBridge.
Give a SIEM one OCSF feed of CloudTrail, flow logs and findings from every account.

Security Lake in one paragraph

Security Lake collects AWS sources (CloudTrail management and data events, VPC flow logs, Route 53 Resolver query logs, EKS audit logs, AWS WAF logs and Security Hub findings) and custom sources, converts them to OCSF in Apache Parquet, and stores them in S3 in your account. A rollup Region can combine data from several Regions, and a delegated administrator can enable it for the whole organization. Subscribers read the data either with query access (for example Athena through Lake Formation) or data access (objects plus notifications, typical for a SIEM).

Think of it like · a bank’s vault and its CCTV archive

Protecting valuables and keeping evidence.

AWS concept		Familiar thing
Macie policy finding	≈	Alarm that the vault door was left unlocked
Macie sensitive data finding	≈	A guard finds customer files lying on a desk
EventBridge	≈	The alarm line to the security desk, always connected
Security Hub CSPM	≈	The weekly risk report, which by default only lists the unlocked doors
Security Lake	≈	The central CCTV archive where every branch’s footage is stored in one format
Subscriber	≈	The police detective who is allowed to watch the archive

Real AWS example · route Macie sensitive data findings to a team

An EventBridge rule for high-severity sensitive data findings.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": {
    "category": ["CLASSIFICATION"],
    "severity": { "description": ["High"] }
  }
}

Policy findings have category POLICY; sensitive data findings have CLASSIFICATION. Target an SNS topic or a Step Functions workflow.

Exam-style scenario

A company uses Macie automated sensitive data discovery. The security team triages everything in Security Hub CSPM but never sees Macie findings about credit card numbers there, although bucket policy findings appear. What should it do?

A. Enable GuardDuty S3 Protection.
B. Change Macie’s publication settings to also publish sensitive data findings to Security Hub CSPM.
C. Lower the Macie publication frequency to 15 minutes.
D. Create a Security Hub CSPM automation rule to import Macie findings.

Show the worked answer

Answer: B

By default Macie publishes only policy findings to Security Hub CSPM. Sensitive data findings must be added in the publication settings.

Why not the others

A: S3 Protection detects suspicious API activity, not data content.
C: Frequency affects updates to policy findings, not which types are sent.
D: Automation rules change findings that already arrived; they cannot import them.

How the exam tests this

“Find PII or credentials in S3 objects”→ Macie sensitive data findings.
“Alert when a bucket becomes public”→ Macie policy finding → EventBridge.
“Sensitive data findings missing in Security Hub”→ Change Macie publication destinations.
“One normalised store for all security logs”→ Security Lake (OCSF, Parquet).
“SIEM needs Security Lake objects and notifications”→ Data access subscriber.

Must remember

Macie → EventBridge always, both finding types.
Security Hub CSPM default: policy findings only.
Updated policy findings: 15 min cycle by default.
Suppressed Macie findings are not published.
Security Lake = OCSF + Parquet in your S3, no detection.

Official sources: Configuring publication settings for Macie findings Types of Macie findings What is Amazon Security Lake? OCSF in Security Lake

Regular assessments: AWS Config conformance packs and State Manager

The second half of skill 1.1.5 is about checks that run again and again without a person. AWS Config rules check resource settings every time they change or on a schedule. Conformance packs bundle many rules and their fixes into one deployable unit. Systems Manager State Manager does the same idea inside your servers: it applies and re-checks a configuration on a schedule.

Concept profile

AWS Config conformance pack

often confused with Security Hub CSPM standard

?What is it?

A collection of AWS Config rules and remediation actions written in a YAML template and deployed as one unit in an account and Region, or across an organization.

⚙How does it work?

Start from a sample template (for example operational best practices for CIS, PCI DSS, NIST or HIPAA) or write your own.
Rules can be AWS managed or custom (Lambda or Guard policy). Each rule is triggered by configuration changes, periodically, or both.
Remediation actions run SSM Automation runbooks, manually or automatically, with retries.
Deploy across the organization with put-organization-conformance-pack from the management account or a delegated administrator.
Templates can be stored as SSM documents and deployed by name.

{ }Structure

Rules evaluate, packs bundle, runbooks fix; State Manager keeps servers in shape.

⇄Conformance pack vs Security Hub CSPM standard

	Conformance pack	Security Hub CSPM standard
You choose the rules?	Yes, any managed or custom rule	No, AWS defines the controls
Remediation built in	Yes, in the template	No; use EventBridge or automation
Output	Config compliance per rule and pack	Control findings and a security score
Custom checks	Easy: custom Lambda or Guard rules	Not supported as controls
Exam hint	“custom rules with remediation, deploy as one unit”	“FSBP / CIS score across accounts”

!Common mistakes the exam tests

Forgetting the configuration recorder: Config rules cannot evaluate resources Config does not record.
Choosing a periodic rule for “detect within minutes of a change”: use a change-triggered rule.
Writing a Lambda function to fix each resource instead of a remediation action with an SSM Automation runbook.
Using State Manager to check AWS resource settings such as bucket encryption: that is AWS Config. State Manager works on managed nodes (and Automation runbooks).
Building associations that rely on the service-linked role: AWS is phasing that out, so give associations a custom IAM role.

✓Benefits and use cases

Deploy “encryption everywhere” rules plus auto-fixes to every account in one step.
Prove continuous compliance with a framework.
Keep agents installed, inventory collected and patches applied on every server.

State Manager associations

A State Manager association binds an SSM document, its parameters, targets (tags, node IDs, a resource group or all managed nodes) and a schedule (rate() or cron()). It runs when created, then on schedule, and again when a new node joins the targets. Typical security uses are AWS-GatherSoftwareInventory for regular inventory, AWS-RunPatchBaseline in Scan mode for patch compliance, and installing or updating the CloudWatch or security agents. Results appear as association status and in Systems Manager Compliance, which Security Hub CSPM and Config can also read. Note that API calls made by the document during the run are not logged in CloudTrail.

Think of it like · an apartment building manager

Keeping a building safe week after week.

AWS concept		Familiar thing
AWS Config rule	≈	An inspector who checks a flat every time something changes in it
Periodic rule	≈	The yearly gas-safety check, whether anything changed or not
Conformance pack	≈	A full inspection checklist plus the repair steps, handed to every building in the city
Remediation action	≈	The handyman who fixes a broken lock as soon as the inspector reports it
State Manager association	≈	The cleaning rota: every Monday, every flat with a ‘tenant’ tag gets the same service
Compliance	≈	The signed sheet on the door showing which flats were done

Real AWS example · a State Manager association for daily patch scanning

Scan all production instances every day at 02:00 UTC; never install.

$ aws ssm create-association --association-name daily-patch-scan \
    --name AWS-RunPatchBaseline \
    --parameters Operation=Scan \
    --targets Key=tag:Environment,Values=prod \
    --schedule-expression "cron(0 2 ? * * *)" \
    --compliance-severity HIGH
{ "AssociationDescription": { "AssociationId": "8dfe3659-example",
  "Name": "AWS-RunPatchBaseline", "ScheduleExpression": "cron(0 2 ? * * *)" } }

Missing patches then show as non-compliant in Systems Manager Compliance. Use Operation=Install in a maintenance window to fix them.

Exam-style scenario

A company must check every account in its organization for unencrypted EBS volumes and public S3 buckets, fix them automatically, and add custom checks of its own later. The rules and fixes must be deployed and versioned as one unit. What should it use?

A. Security Hub CSPM FSBP standard.
B. An organization conformance pack with managed and custom Config rules and SSM Automation remediation actions.
C. A State Manager association running a shell script daily.
D. GuardDuty with S3 Protection.

Show the worked answer

Answer: B

Conformance packs bundle rules and remediations in one template and deploy across the organization. Custom rules can be added later.

Why not the others

A: Finds problems but does not fix them and cannot hold custom checks.
C: State Manager runs inside managed nodes; it is not built to evaluate AWS resource settings.
D: GuardDuty detects threats, not misconfigurations.

How the exam tests this

“Rules and remediations deployed as one unit”→ Conformance pack.
“Same pack in every account”→ Organization conformance pack.
“Fix a non-compliant resource automatically”→ Config remediation action (SSM Automation).
“Collect inventory on servers every day”→ State Manager association with AWS-GatherSoftwareInventory.
“Detect a change within minutes”→ Change-triggered Config rule.

Must remember

Conformance pack = YAML: rules + remediation.
Config needs the recorder on.
Remediation = SSM Automation runbook.
Association = document + targets + schedule.
Config checks AWS resources; State Manager manages nodes.

Official sources: Conformance packs Managing conformance packs across an organization Remediating noncompliant resources About State Manager associations

Cheatsheet extras: AWS Config building blocks and what changed since older material

The cheat sheet calls AWS Config “a big part of the exam” and lists its building blocks: configuration items, history, snapshots, the stream, the recorder and its role. Today’s lecture used Config through conformance packs and Security Hub; this section fills in the foundation underneath, and corrects older facts about Inspector, Macie, GuardDuty and Security Hub.

Concept profile

AWS Config recorder

often confused with AWS CloudTrail

?What is it?

The part of AWS Config that watches your resources and writes a configuration item (CI) each time a supported resource is created, changed or deleted. It is the inventory and history that every Config rule, conformance pack and Security Hub CSPM control depends on.

⚙How does it work?

Regional: turn on a recorder in every account and Region you use (Control Tower and Quick Setup do this for you). Global resources such as IAM users are recorded in one Region only.
Needs permissions: the service-linked role AWSServiceRoleForConfig, or a custom role that trusts config.amazonaws.com with the AWS_ConfigRole managed policy plus write access to the bucket and sns:Publish on the topic.
Terms: CI (one point-in-time record), configuration history (all CIs of one resource), snapshot (all resources at one moment), configuration stream (change notifications on SNS).
Recording frequency: continuous (every change) or daily (periodic, cheaper for noisy resource types).
The resource timeline shows each change, its relationships and a link to the CloudTrail event that caused it.

{ }Structure

Change → configuration item → bucket and topic; rules and the timeline read the CIs.

⇄AWS Config recorder vs AWS CloudTrail

	AWS Config recorder	AWS CloudTrail
Question it answers	“What did this resource look like, and when did it change?”	“Who called which API, from where?”
Record	Configuration item (state)	Event (API call)
Scope switch	Per Region; choose resource types	Trail per Region or all Regions; event types
Can judge compliance	Yes, with Config rules	No
Exam hint	“configuration history”, “drift”, “inventory”	“which user”, “source IP”, “API activity”

!Common mistakes the exam tests

Using Config to find who made a change: Config shows what changed and links to CloudTrail for the who.
Turning on Config in one Region and expecting other Regions to be recorded.
Custom role trusting s3.amazonaws.com instead of config.amazonaws.com, or an SNS topic policy that doesn’t allow Config to publish: no notifications.
Not alerting on StopConfigurationRecorder or DeleteDeliveryChannel: an attacker can quietly stop recording.
Expecting rules to work for resource types the recorder isn’t recording.

✓Benefits and use cases

Inventory of every resource and its relationships.
Before/after view of a change during an investigation.
The data source for Config rules, conformance packs and Security Hub CSPM.

Think of it like · a house inventory photographer

Config takes a photo of every room each time something moves; CloudTrail is the door camera.

AWS concept		Familiar thing
Configuration item	≈	One photo of one room, with the time written on it
Configuration history	≈	The photo album of one room
Configuration snapshot	≈	Photos of every room taken at the same moment
Configuration stream (SNS)	≈	A text message each time a new photo is taken
Recorder per Region	≈	A separate photographer for each house you own
CloudTrail link in the timeline	≈	The door camera clip showing who walked in before the furniture moved

Real AWS example · check that recording works and read a resource’s history

Two CLI calls an investigator runs first.

$ aws configservice describe-configuration-recorder-status
{ "ConfigurationRecordersStatus": [ {
    "name": "default", "recording": true,
    "lastStatus": "SUCCESS", "lastStatusChangeTime": "2026-10-19T08:02:11Z" } ] }

$ aws configservice get-resource-config-history \
    --resource-type AWS::EC2::SecurityGroup --resource-id sg-0a1b2c3d \
    --limit 2 --query "configurationItems[].[configurationItemCaptureTime,relatedEvents]"
[ [ "2026-10-18T22:41:05Z", [ "6f1c2e0a-…-cloudtrail-event-id" ] ],
  [ "2026-10-02T09:10:44Z", [] ] ]

"recording": true proves the recorder is on in this Region. relatedEvents holds the CloudTrail event ID: look it up to see which principal opened the port.

Exam-style scenario

An auditor asks: “Show us what security group sg-0a1b looked like before last Tuesday’s change, what it looked like after, and which IAM principal made the change.” AWS Config and a multi-Region trail are enabled. What is the quickest way to answer?

A. Search CloudTrail event history only.
B. Open the AWS Config resource timeline for sg-0a1b to compare the configuration items, and follow the linked CloudTrail event to see the principal.
C. Run an Amazon Inspector network reachability scan.
D. Query VPC flow logs for the security group.

Show the worked answer

Answer: B

Config holds the before and after state; the CloudTrail event linked from the timeline gives the identity and source IP.

Why not the others

A: Shows who called the API and the request, but not the full before/after state of the group.
C: Inspector reports reachability now, not history.
D: Flow logs show traffic, not configuration or who changed it.

Older study material vs today

Your cheat sheet was written for the older exam. These detection services have changed, so learn the right-hand column.

Topic	Older study material says	Today (use this on the exam)
Amazon Inspector	Inspector Classic: assessment targets and templates, rules packages (CVE, CIS, network reachability), install the Inspector agent, run on a schedule	Amazon Inspector scans continuously and automatically (EC2 through the SSM Agent or agentless, ECR images, Lambda). No templates or runs. See Infrastructure Security Day 5.
Amazon Macie	Macie Classic read CloudTrail data events and created its own trail bucket	Macie works on S3 only: bucket inventory and security posture, plus sensitive data discovery jobs and automated discovery. To see who read the objects, use CloudTrail S3 data events or server access logs.
GuardDuty data	“Uses CloudTrail, VPC flow logs and DNS logs”	Still true for foundational sources, read from AWS’s own independent streams: you don’t need to turn those logs on. Protection plans add S3, EKS, runtime, malware, RDS and Lambda.
GuardDuty start-up	“7–14 days to build a baseline”	Threat-intelligence findings appear right away; only anomaly-based findings need time to learn normal behavior. The 30-day free trial still applies.
Security Hub	“CIS checks via Config, about 12 hours”	Security Hub CSPM controls run on service-linked Config rules, so the Config recorder must be on for the resource types. Findings flow to EventBridge as `Security Hub Findings - Imported`.
Trusted Advisor	A security checker for root MFA, open security groups, public snapshots, key rotation	Still useful, but it is a best-practice reviewer, not a threat detector. Covered in Governance Day 3.

“Track configuration changes” → AWS Config. “Record API calls and who made them” → CloudTrail. Answers that swap them (Config records API calls, CloudWatch tracks configuration, Macie tracks configuration) are the classic distractors.

How the exam tests this

“History of how a resource was configured”→ AWS Config configuration history / timeline.
“Who changed it”→ CloudTrail (linked from the Config timeline).
“Config notifications never arrive”→ Role trusts config.amazonaws.com; SNS topic policy allows sns:Publish; role can write to the bucket.
“Make sure nobody quietly stops Config”→ Alert on StopConfigurationRecorder / DeleteDeliveryChannel; block with an SCP.
“Find PII in S3, then who read it”→ Macie for discovery + CloudTrail data events for access.

Must remember

Config is Regional: one recorder per account per Region.
CI → history → snapshot → stream (SNS).
Config = what; CloudTrail = who.
Inspector Classic and Macie Classic are retired; learn the current services.
GuardDuty reads its own copies of the logs; no need to enable them.

Official sources: AWS Config concepts Recording AWS resources Permissions for the Config IAM role SNS topic permissions for Config GuardDuty foundational data sources What is Amazon Inspector?

Lecture summary map

Day 2 on one screen.

1. Mind map

Tap a branch to jump back to that part of the lecture. Try redrawing this map from memory on paper.

2. Match the requirement to the service

The left column is the exam wording; the right column is the answer.

3. “If the question says… pick…”

Malicious activity, no agents, no log setupGuardDuty foundational sources

Threats inside containers or EC2 processesGuardDuty Runtime Monitoring

Scan uploads before users open themMalware Protection for S3 + tags

Many weak signals, one Critical storyExtended Threat Detection

Hide known-good findings from the SIEMGuardDuty suppression rule

GuardDuty for every account and RegionDelegated admin + auto-enable ALL

CIS / FSBP / PCI DSS scoreSecurity Hub CSPM standards

Controls show no dataTurn on AWS Config recording

Correlate signals into exposuresSecurity Hub (2025), OCSF

Same CSPM settings org-wideCentral configuration policy

PII in S3 must page someoneMacie → EventBridge rule

Rules + fixes as one unit, org-wideOrganization conformance pack

Day 2 in one sentence

GuardDuty finds attackers, Macie finds exposed data, Security Hub brings it all together, and Config and State Manager keep checking on a schedule.

Must-remember cheat sheet

1. GuardDuty foundational: CloudTrail mgmt, VPC flow, DNS.

2. GuardDuty is Regional; enable in every Region.

3. Runtime Monitoring = agent on EKS, ECS Fargate, EC2.

4. Malware for EC2: agentless EBS scans.

5. Malware for S3: new uploads, result tags, works standalone.

6. Attack sequences: Critical, free, 24-hour window.

7. Suppression = archived, not forwarded.

8. Lists: 1 trusted IP + 1 trusted entity, 6 threat per account per Region.

9. GuardDuty admin: same account in all Regions, 50,000 members.

10. Old Security Hub = Security Hub CSPM (ASFF).

11. New Security Hub: exposures, OCSF.

12. CSPM controls need AWS Config.

13. Automation rules: admin, per Region, max 100.

14. Enable list blocks new controls.

15. Macie → Security Hub CSPM: policy findings by default.

16. Conformance pack = rules + remediation YAML.

17. Config = what changed; CloudTrail = who changed it.

18. Config role trusts config.amazonaws.com; topic allows sns:Publish.

19. Inspector/Macie Classic are gone; learn today’s versions.

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 3.

Practice test questions (from your mock exams)

These 9 questions match today’s topics: 8 come from your own SCS-C03 mock exams and 1 was added to cover a recent AWS change. Wording was modernized where services were renamed (for example CloudWatch Events is now Amazon EventBridge), and each answer was checked against current AWS behavior; where the mock’s answer key was wrong, the explanation says so. The source (mock and question number) is at the end of each explanation.

Hands-on lab (30 minutes, low cost)

In one Region, enable GuardDuty (new accounts get a 30-day free trial). Under Settings, choose Generate sample findings and open a CryptoCurrency sample to read its resource, action and severity.
Create an EventBridge rule with the pattern {"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"]} and an SNS email target. Generate sample findings again and check your inbox.
Create a GuardDuty suppression rule for one sample finding type and confirm new copies land in Archived, not in your email.
Enable Security Hub CSPM with only the FSBP standard (AWS Config must be recording). After a few hours, open the failed controls and the security score.
In AWS Config, deploy a small conformance pack from a sample template (for example operational best practices for S3) and look at its compliance view.
If you have one EC2 instance with SSM Agent, create a State Manager association with AWS-GatherSoftwareInventory, targeted by tag, schedule rate(1 day).
Clean up: delete the conformance pack, disable Security Hub CSPM and the Config recorder, delete the EventBridge rule and SNS topic, and disable or suspend GuardDuty. After the free trials, GuardDuty, Security Hub CSPM and Config items are charged, and Macie charges per GB inspected, so do not leave them running in a personal account.

Official sources: GuardDuty sample findings What is Security Hub CSPM? Conformance packs