Monitoring & Alerting

The detection catalog, sorted by job

A question stem might read: "a security team needs to be told when an EC2 instance starts talking to a known cryptomining domain." The fastest way to the answer is to refuse to memorize service brochures and instead sort the catalog by the one job each service does. Six services cover AWS detection, and no two share a job, so the description of a job points to exactly one service.

Amazon GuardDuty^[1] is the threat detector: it continuously reads telemetry and raises findings when behavior looks malicious or anomalous, such as the cryptomining-domain example above. Amazon Macie^[2] is the sensitive-data discovery service: it scans Amazon S3 and classifies objects that hold PII, credentials, or financial data. AWS Security Hub^[3] (the current console brands it Security Hub CSPM, for cloud security posture management) is the aggregator and posture grader: it pulls findings from the other detectors and runs control-based checks against standards. Amazon Security Lake^[4] is the central log lake: it normalizes logs into one schema for analytics. Amazon Detective^[5] is the investigation graph you open after a finding. AWS Config^[6] is the resource-compliance recorder: it tracks how each resource is configured over time and grades it against rules.

The trap the exam sets is offering two services that both "sound like detection." GuardDuty and Security Hub both surface findings, but only GuardDuty analyzes raw CloudTrail, VPC Flow, and DNS telemetry to create a finding; Security Hub never inspects that telemetry, it only ingests findings other services already made. Hold each candidate answer against the job in the stem and the lookalike falls away.

The six AWS detection services, one box per job; a stem describing one job matches exactly one box.

GuardDuty, Macie, Security Hub: what each finds

Lead with the rule: GuardDuty detects threats from activity, Macie finds sensitive data at rest, and Security Hub grades and merges what the others report. The three blur together only until you pin down their inputs and outputs.

GuardDuty runs on three foundational data sources that are always on, need no agents, and cost nothing extra: AWS CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs^[7]. CloudTrail S3 data events are not foundational; they are monitored only when you turn on the optional S3 Protection plan, and other optional plans add EKS Runtime Monitoring, RDS login activity, Lambda network activity, and Malware Protection. Each finding carries a severity on a 1.0 to 10.0 scale: Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0^[8], and that number is what your alerting filters on.

Macie reads Amazon S3 objects and produces two finding kinds: sensitive-data findings (an object matched a managed or custom data identifier for PII, secrets, and the like) and policy findings (a bucket's settings weakened, for example public access or encryption disabled). It publishes to Security Hub natively in its own integration^[9], and separately to EventBridge; the Security Hub path is direct, not "via EventBridge." By default only new and updated policy findings flow to Security Hub, while sensitive-data findings require opt-in through the publication settings.

Security Hub ingests findings from GuardDuty, Macie, Inspector, and partner products, normalizes them, and layers on its own security controls grouped into standards such as the AWS Foundational Security Best Practices (FSBP) and CIS. Its recommended configuration enables FSBP and all its controls. The output is one prioritized list plus per-account control scores, which is why an exam answer that wants a single pane of glass across many accounts is Security Hub, not a second copy of GuardDuty. The figure below lines up each service against its inputs and its output so the three stop blurring.

Each service against its inputs and its output: GuardDuty reads telemetry, Macie reads S3, Security Hub consumes the others' findings.

From finding to alert: the EventBridge pattern

The single most reusable pattern in this domain is that detection services do not notify anyone by themselves. A finding is published as an event to the default Amazon EventBridge bus, an EventBridge rule matches it by source and fields like severity, and the rule's targets carry out the response. Build the alerting once at the EventBridge layer and every detector inherits it, instead of wiring each service to Amazon SNS separately. The figure below traces that one path: detectors on the left feed a single rule in the middle that fans out to the targets on the right.

A rule that pages a human on serious GuardDuty findings looks like this:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 7] }] }
}

That rule fires only for High and Critical findings (severity 7.0 and above) and sends the event to an SNS topic for on-call notification. Swap the target for an AWS Lambda^[10] function and the same finding triggers automated remediation, for example isolating an instance's security group; swap it for AWS Step Functions to run a multi-step response workflow. Security Hub adds automation rules and supports custom actions that send a chosen finding to EventBridge on demand, but the underlying alert path is identical.

When you need the raw events for later replay rather than an immediate page, an EventBridge archive^[11] captures matching events; its retention is configurable in days and defaults to indefinite, not 24 hours. Pair that with the logging-solutions subtopic for durable storage, and with responding-to-events for what the Lambda or Step Functions target actually does.

Findings land on the default EventBridge bus; one rule matching source and severity fans out to SNS, Lambda, or Step Functions.

Aggregating across an Organization

At scale the question shifts from "which service" to "how do I see all of it at once without logging into 200 accounts." The answer is the delegated administrator model, shared by GuardDuty, Macie, Security Hub, Detective, and Config. The Organizations management account designates one member account as the service's delegated admin, and from then on that account enables, configures, and views findings for every member in every Region. AWS guidance, and the exam's expected answer, is to make that delegated admin a dedicated security or audit account rather than the management account itself, keeping detection authority separate from billing and account creation.

Security Hub extends this with central configuration^[12]. After integrating Security Hub with AWS Organizations, the delegated admin works from one home Region (which doubles as the aggregation Region, receiving findings from all linked Regions) and writes configuration policies that declare whether Security Hub is on, which standards are enabled, and which controls run. A policy is associated with a target, meaning an account, an OU, or the org root, and it takes effect in the home Region and all linked Regions. Targets are centrally managed (only the delegated admin can change them, which blocks configuration drift) or self-managed (the account sets its own configuration per Region). Children inherit the closest parent's policy unless one is applied directly, and an applied policy always wins over inheritance.

Detective and Config follow the same delegated-admin shape for cross-account reach. Config also assesses compliance organization-wide through conformance packs: a conformance pack^[13] is a collection of Config rules and remediation actions packaged as a single YAML template (optionally stored as a Systems Manager document) and deployed in one account-and-Region or across the whole organization from the delegated admin. For drift you want corrected automatically rather than just flagged, AWS Systems Manager State Manager enforces a desired configuration on a schedule. Plan the account layout alongside multi-account-governance.

The management account delegates a security account, which aggregates member findings up and pushes Security Hub config policies down OUs.

Which detection service does which job

Service	Primary job	Reads / consumes	Produces
Amazon GuardDuty	Threat detection	CloudTrail mgmt events, VPC Flow Logs, Route 53 DNS logs	Findings (severity 1.0-10.0)
Amazon Macie	Sensitive-data discovery	Amazon S3 objects	Sensitive-data + policy findings
AWS Security Hub	Posture aggregation (CSPM)	Findings from GuardDuty/Macie/Inspector/partners	Normalized findings + control scores
Amazon Security Lake	Central log lake	AWS + custom log sources	OCSF Parquet on S3 for subscribers
Amazon Detective	Investigation	GuardDuty findings, CloudTrail, VPC Flow Logs	Behavior graph (up to ~1 year)
AWS Config	Resource compliance	Resource configuration changes	Compliance state + conformance-pack results

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Sort detection services by job, because no two share one

GuardDuty detects threats from activity, Macie discovers sensitive data in S3, Security Hub aggregates findings and grades posture, Security Lake centralizes raw logs, Detective investigates a finding, and Config tracks resource compliance. Each does exactly one job, so a question stem that describes a job points to one service. Match the symptom in the stem to the job rather than recalling marketing names, and the lookalike answers fall away.

Trap Picking Security Hub when the stem asks to detect a brand-new threat from network or DNS activity; Security Hub only ingests findings others created, it never analyzes that telemetry itself.

GuardDuty is the detector; Security Hub is the aggregator

GuardDuty analyzes telemetry and produces findings, while Security Hub consumes findings from GuardDuty, Macie, Inspector, and partners into one normalized list and adds control-based posture scores. The exam confuses them because both surface findings, but only GuardDuty creates them from raw activity. Reach for Security Hub when the requirement is a single prioritized view across many accounts plus compliance grading, and GuardDuty when the requirement is finding the threat in the first place.

GuardDuty's three foundational sources are always on and free

GuardDuty's foundational data sources are AWS CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs; they need no agents, no setup, and carry no extra ingestion cost. CloudTrail S3 data events are not foundational, they are covered only by the optional S3 Protection plan, and other optional plans add EKS Runtime Monitoring, RDS login activity, Lambda network activity, and Malware Protection. Knowing which sources are built in tells you what GuardDuty catches before you enable anything else.

Trap Listing 'CloudTrail management and data events' as foundational; S3 data-event monitoring requires turning on the S3 Protection plan.

3 questions test this

GuardDuty severity runs 1.0 to 10.0 across four bands

Each GuardDuty finding gets a severity value on a 1.0 to 10.0 scale, bucketed as Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, and Critical 9.0-10.0. That number is the field your EventBridge alerting filters on, for example paging only on findings of 7.0 and above. Critical means an attack sequence may be in progress, so it is the band you wire to immediate response rather than a daily digest.

2 questions test this

Macie classifies sensitive data in Amazon S3 only

Macie scans Amazon S3 objects and raises sensitive-data findings when it matches managed or custom data identifiers for PII, credentials, and financial data, plus policy findings when a bucket's settings weaken. It does not scan databases, EBS volumes, or network traffic, and it does not detect threats. When a scenario is 'where is our regulated data sitting,' that is Macie; when it is 'is someone attacking us,' that is GuardDuty.

Trap Choosing Macie to scan an RDS database or EBS volume for sensitive data; Macie's discovery is scoped to S3 objects.

Macie publishes to Security Hub directly, not via EventBridge

Macie sends findings to Security Hub through a native integration and, separately, to EventBridge as its own destination; the Security Hub delivery does not route through EventBridge. By default only new and updated policy findings are published to Security Hub, while sensitive-data findings must be opted in through the publication settings. So if sensitive-data findings are missing from Security Hub, the fix is the publication setting, not an EventBridge rule.

Trap Assuming sensitive-data findings reach Security Hub automatically; only policy findings do by default, sensitive-data findings need opt-in.

2 questions test this

Security Hub grades accounts with controls grouped into standards

Security Hub runs security controls grouped into standards such as the AWS Foundational Security Best Practices (FSBP) and CIS, producing a posture score per account on top of the findings it aggregates. The recommended configuration enables FSBP and all of its controls, including new ones as they ship. When a question wants continuous benchmarking of accounts against a best-practice standard, that scoring is Security Hub's job, distinct from GuardDuty's threat findings.

Detective investigates a finding with a behavior graph

Detective is the investigation layer, not a detector: it pulls CloudTrail, VPC Flow Logs, and GuardDuty findings into a behavior graph using machine learning and graph analysis so an analyst can trace root cause and blast radius across up to about a year of history. You open it after a finding fires to answer 'what else did this principal touch.' It does not create findings and it is not a place to run ad-hoc SQL over raw logs.

Trap Treating Detective as a detector that raises its own findings; it visualizes and correlates existing telemetry, it does not generate findings.

4 questions test this

Findings become alerts through an EventBridge rule, not the service

Detection services do not notify anyone on their own; a finding is published to the default EventBridge bus, an EventBridge rule matches it by source and a field like severity, and targets such as SNS, Lambda, or Step Functions carry out notification or automated response. Build the alerting once at the EventBridge layer and every detector inherits it. A rule filtering severity at 7.0 and above, for instance, pages on-call only for High and Critical GuardDuty findings.

Trap Wiring each detection service to its own SNS topic separately; the reusable pattern centralizes matching in one EventBridge rule that all detectors feed.

4 questions test this

EventBridge archive defaults to indefinite retention

An EventBridge archive captures matching events for later replay, and its retention is configurable in days but defaults to indefinite, not 24 hours. Use it when you need to retain or re-drive detection events rather than just page on them live. The replay lets you reprocess past findings through a new rule or target without the original events being gone.

Aggregate org-wide through a delegated administrator account

GuardDuty, Macie, Security Hub, Detective, and Config each let the Organizations management account designate one member as the delegated administrator, which then enables, configures, and views findings for every member across Regions from one place. AWS guidance, and the exam answer, is to put that role in a dedicated security or audit account, not the management account, keeping detection authority separate from billing and account creation. This is how you avoid logging into hundreds of accounts to see findings.

Trap Making the Organizations management account the delegated administrator for detection; best practice delegates to a separate security account.

Security Hub central configuration pushes policies from a home Region

After integrating Security Hub with AWS Organizations, the delegated admin uses central configuration to write configuration policies from one home Region that declare whether Security Hub is on and which standards and controls run, taking effect in the home Region and all linked Regions. Targets (an account, OU, or root) are centrally managed, so only the delegated admin can change them, which blocks configuration drift, or self-managed, so the account configures itself per Region. An applied policy always wins over an inherited one.

Trap Expecting a centrally managed account to change its own standards locally; central configuration removes that, only the delegated admin can, which is the point.

The home Region doubles as the Security Hub aggregation Region

In Security Hub central configuration the home Region is both where the delegated admin authors configuration policies and the aggregation Region that receives findings, insights, and data from all linked Regions. Pick it deliberately, because an opt-in Region (any introduced on or after March 20, 2019) cannot be the home Region, though it can be a linked Region. Cross-Region aggregation is what gives you a single multi-Region view of posture.

5 questions test this

Config conformance packs deploy rules as one org-wide unit

A conformance pack is a collection of AWS Config rules and remediation actions packaged as a single YAML template, optionally stored as a Systems Manager document, and deployed in one account-and-Region or across the whole organization from the delegated admin. It is how you assess compliance against a baseline like PCI or operational best practices in one deployable entity instead of wiring rules one at a time. Config tracks resource configuration over time; the pack turns that into a graded compliance result.

1 question tests this

A healthcare company needs to deploy a standardized set of AWS Config rules across all AWS accounts in their organization to meet HIPAA…

Use State Manager to enforce configuration, not just flag it

AWS Config and conformance packs detect and report noncompliant resource configuration, but they do not by themselves keep a setting in place. AWS Systems Manager State Manager enforces a desired configuration on a schedule, reapplying it when something drifts. Reach for State Manager when the requirement is automatic correction of drift rather than a finding that a human or separate remediation must act on.

Trap Expecting an AWS Config rule on its own to fix a drifted setting; a rule evaluates compliance, enforcement comes from a remediation action or State Manager.

Inspector findings flow into Security Hub, it is the scanner not the hub

Amazon Inspector continuously scans EC2 instances, container images in ECR, and Lambda functions for software vulnerabilities (CVEs) and unintended network exposure, then publishes its findings into Security Hub alongside GuardDuty and Macie. Inspector is the vulnerability detector; Security Hub is where its findings are aggregated and prioritized. When a stem asks which service finds unpatched CVEs on workloads, that is Inspector, with Security Hub as the place you review them.

GuardDuty re-sends repeat findings every 6 hours by default; only the admin can shorten it

GuardDuty pushes a brand-new finding (unique finding ID) to EventBridge in near real time, but it aggregates subsequent occurrences of the same finding type into a single event on a notification frequency that defaults to 6 hours (configurable to 15 minutes or 1 hour). Only the administrator account can change this frequency for subsequent occurrences; a member account cannot, and the administrator's setting applies to all member accounts.

Trap Reading EventBridge firing only on a finding's first occurrence as a broken event pattern; it is the default 6-hour aggregation cadence for repeats.

3 questions test this

Detective finding groups correlate GuardDuty findings into a MITRE ATT&CK attack chain

Amazon Detective finding groups examine multiple related GuardDuty findings and the entities involved (such as IPs, users, and resources) that are likely part of the same event, and map the group's tactics, techniques, and procedures (TTPs) to the MITRE ATT&CK framework. A finding group offers a generative-AI natural-language summary of the attack narrative (powered by models on Amazon Bedrock) plus a graph-based visualization showing how the entities connect the findings.

Trap Reaching for a behavior-graph entity profile to see the cross-finding attack chain; the correlated, TTP-mapped view is the finding group, not an individual entity profile.

4 questions test this

Security Hub custom actions are how an analyst manually pushes selected findings to EventBridge

Security Hub auto-streams every new finding and finding update to EventBridge for automated rules, but to act on only specific findings on demand you create a custom action; when an analyst selects findings (or insight results) and chooses it, Security Hub emits an event carrying the custom action ARN that an EventBridge rule matches to invoke a Lambda or ticketing integration. This is the supported pattern for combining automatic remediation with manual, on-demand routing.

Trap Building a separate console button or polling job for manual routing; the on-demand path is a Security Hub custom action matched by its ARN in an EventBridge rule.

4 questions test this

Security Hub insight filters are AND across attributes, OR within one attribute

A Security Hub custom insight combines filters on different attributes with AND and filters on the same attribute with OR, so 'Product name is GuardDuty' plus 'Product name is Amazon Inspector' plus 'Resource type is AwsS3Bucket' means (GuardDuty OR Inspector) AND S3. A grouping attribute (such as AwsAccountId or ResourceId) defines the insight result, and the insight spans the home Region and all linked Regions unless you add a Region filter.

Trap Expecting two values of the same attribute to AND together; same-attribute filters OR, so listing two product names widens rather than narrows the insight.

6 questions test this

Security Hub ALL_REGIONS linking mode auto-includes future Regions in aggregation

Security Hub cross-Region aggregation is off until you explicitly enable it from the aggregation (home) Region. Setting RegionLinkingMode to ALL_REGIONS aggregates findings from every Region where Security Hub is enabled and automatically aggregates findings from new Regions as Security Hub supports them and you opt into them, which is what satisfies a requirement to include future Regions without reconfiguration.

Trap Listing specific linked Regions (SPECIFIED_REGIONS) when the requirement is to auto-include future ones; only ALL_REGIONS (or ALL_REGIONS_EXCEPT_SPECIFIED) adds new Regions automatically.

5 questions test this

The detection catalog, sorted by job

GuardDuty, Macie, Security Hub: what each finds

From finding to alert: the EventBridge pattern

Aggregating across an Organization

Which detection service does which job

Decision tree

Cheat sheet

Also tested in

References