Detection practice questions

Security Hub CSPM sends every new or updated finding to EventBridge as a "Security Hub Findings - Imported" event. An administrator account's event feed includes its member accounts' findings, and the home (aggregation) Region's feed includes findings from the linked Regions.

Two facts combine here. First, the administrator account sees finding events for all member accounts, so rules do not need to exist in each member. Second, with cross-Region aggregation the home Region's event feed carries findings from the linked Regions in near real time, so rules do not need to exist in each Region. One set of rules in the administrator account in us-east-1 therefore covers every account and Region. Creating rules in the other Regions too still works but duplicates coverage; rules in member accounts multiply the copies.

1. Ask which account sees events for every member: the Security Hub CSPM administrator account.
2. Ask which Region sees events for every Region: the home Region, once aggregation links the others.
3. Combine the two: one rule set, administrator account, home Region.
4. Reject the options that still work but multiply rule copies by Region or by account.

Exam tip: Security Hub CSPM alerting rules go in the administrator account in the home Region; aggregation already brings every account and linked Region there.

GuardDuty is a Regional service: the delegated administrator must be designated, and organization auto-enable configured, in each Region. Auto-enable can be ALL (existing and new members), NEW (accounts that join later) or NONE.

The requirement has two parts: existing gaps and future accounts, in four Regions. Auto-enable set to ALL covers both existing and new members, while NEW misses the existing accounts the audit found. And because the delegated administrator and its auto-enable preference are Regional, configuring them in one Region leaves the other Regions uncovered. An SCP can prevent members from disabling GuardDuty but cannot turn it on.

1. Split the requirement: existing accounts and future accounts, in four Regions.
2. Recall that GuardDuty delegated administration and auto-enable are configured per Region.
3. Choose ALL over NEW, because NEW ignores accounts already in the organization.
4. Treat SCPs as guardrails that block actions, not as a way to enable a service.

Exam tip: GuardDuty org coverage = same delegated administrator in every Region + auto-enable ALL (NEW misses existing accounts).

GuardDuty's foundational data sources (CloudTrail management events, VPC flow logs, and DNS query logs for Amazon-provided DNS) are consumed through independent streams of data directly from AWS. Customers do not need to enable these logs for GuardDuty, and disabling them does not affect GuardDuty.

Turning off the accounts' own flow logs and Resolver query logs removes the team's copies of that data, not GuardDuty's: GuardDuty pulls the same telemetry through an independent feed. Its network and DNS findings therefore continue unchanged. The partial answers are tempting because they assume one source is customer-published, but flow and DNS data use the same independent mechanism. Customer-published logs remain useful for the team's own analysis and retention, not for GuardDuty.

1. Identify which GuardDuty sources are involved: VPC flow logs and DNS query logs, both foundational.
2. Recall that foundational sources arrive through GuardDuty's own independent stream, not the account's published logs.
3. Conclude that the customer's log settings have no effect on either finding type.
4. Reject every option that ties a finding type to a customer log setting.

Exam tip: GuardDuty does not need your flow logs or DNS logs: it has its own feed, so turning yours off does not blind it.

GuardDuty separates foundational data sources from optional protection plans. S3 Protection monitors CloudTrail S3 data events, such as GetObject, PutObject and DeleteObject, through GuardDuty's own feed, and can be enabled organization-wide from the delegated administrator.

The scenario describes anomalous object-level access, which only S3 data events reveal; foundational sources include management events only. The S3 Protection plan adds those data events and needs no CloudTrail data-event trail of the customer's own. Malware Protection for S3 is a different S3-related plan that scans uploads for malware, and Runtime Monitoring watches workloads, so neither detects unusual reads by stolen credentials.

1. Classify the activity: object reads are S3 data events.
2. Recall that foundational GuardDuty sources include management events, not S3 data events.
3. Pick the protection plan that adds S3 data events: S3 Protection.
4. Distinguish it from Malware Protection for S3 (scans uploads) and Runtime Monitoring (workload OS events).

Exam tip: Suspicious S3 object access needs the GuardDuty S3 Protection plan; Malware Protection for S3 only scans uploads.

Amazon Security Lake centralizes security data from AWS sources (CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, Security Hub findings and more) across accounts and Regions, normalizes it to the Open Cybersecurity Schema Framework (OCSF), and stores it as Parquet in S3 for subscribers such as SIEMs.

The deciding requirement is aggregating raw logs and findings from every account and Region into one open, vendor-shared schema. Security Lake does exactly this with OCSF. Security Hub CSPM aggregates findings only, in its own format. OpenSearch could index the data but would need a pipeline and mapping per source. CloudTrail Lake is a query store for CloudTrail events, not a normalizing collector for flow and DNS logs.

1. List what is needed: raw logs plus findings, many accounts and Regions, one open schema.
2. Recall that Security Lake aggregates AWS security sources organization-wide and normalizes them to OCSF.
3. Rule out Security Hub CSPM, which aggregates findings only.
4. Rule out OpenSearch and CloudTrail Lake: per-source pipelines, or CloudTrail events only.

Exam tip: Aggregate raw security logs + findings across accounts and Regions in one open schema = Amazon Security Lake (OCSF).

Security Lake stores and normalizes security data but does not detect threats or raise alerts. Detection comes from services such as GuardDuty, whose findings can be routed with EventBridge to paging targets.

The gap is detection, not storage: Security Lake collected the CloudTrail data but nothing analyzed it. GuardDuty adds managed detections, including credential exfiltration from instance roles, and its findings trigger EventBridge rules for paging. Scheduled Athena queries can detect threats but only with custom, maintained logic and a delay. Security Hub CSPM standards check configuration posture, not credential use, and Detective investigates existing findings rather than producing alerts.

1. Identify the missing layer: a threat detector, not more data or posture checks.
2. Pick the managed service that detects credential exfiltration: GuardDuty.
3. Route its findings to the pager with an EventBridge rule and SNS.
4. Reject custom queries (more logic), posture standards (configuration only) and Detective (investigation, not alerting).

Exam tip: Security Lake stores and normalizes; it never alerts. Pair it with a detector such as GuardDuty plus EventBridge routing.