Domain 3 of 4 · Chapter 2 of 5

Improving security

The improvement loop: detect, prioritize, automate the fix

Wire detection straight into remediation and the mean-time-to-remediate drops to seconds instead of waiting on a human to read a ticket queue: that single move is what separates improving the security of a workload that is already running from a one-time review. Four stages repeat forever: a detective service surfaces a finding, AWS Security Hub[1] normalizes and scores it, an automated action closes it, and the next scan verifies the fix held. Because this subtopic is about improving existing posture, the answer is almost always an automated, evidence-driven remediation path rather than a new preventive guardrail (org-wide SCPs/RCPs and Firewall Manager belong to the governance-focused security-controls subtopic) or a from-scratch design (that is security-for-new-solutions).

Normalize everything through ASFF

The loop only works if every signal lands in one format. AWS Security Hub ingests Amazon GuardDuty, Amazon Inspector, Amazon Macie, and IAM Access Analyzer findings in the AWS Security Finding Format (ASFF)[1] and scores accounts against standards such as AWS Foundational Security Best Practices (FSBP), the CIS AWS Foundations Benchmark, NIST SP 800-53 Rev 5, NIST SP 800-171, and PCI DSS. Security Hub is the aggregator and scorer, not a detector; picking it to find a threat is a recurring trap.

Triage before you remediate

Not every finding deserves the same response, so re-rank and de-noise as findings arrive. Security Hub automation rules[2] let the administrator account automatically update finding fields (severity, criticality, workflow status, note) or suppress findings the moment Security Hub ingests or updates them, for example, elevate any S3-bucket finding in a production account to CRITICAL, or set low-value informational findings to SUPPRESSED so they never page anyone. Automation rules apply to both new and updated findings, you can have up to 100 per administrator account, and they are Regional (create the rule in each Region you want it to act in).

Close the loop with EventBridge

The prescribed automated-response pattern routes a finding (from Security Hub, GuardDuty, or AWS Config) through an Amazon EventBridge rule to an AWS Lambda function or an AWS Systems Manager Automation document[3] that performs the fix (re-enable S3 Block Public Access, strip a 0.0.0.0/0 ingress rule, quarantine a compromised instance). When a confirmed incident needs root-cause analysis instead of an automatic fix, pivot from the finding into Amazon Detective[4], which builds a behavior graph from CloudTrail, VPC Flow Logs, and EKS audit logs so an analyst can scope blast radius. Detective investigates; it does not detect or remediate.

Detective service surfaces a finding AWS Security Hub normalizes + scores Automated action closes it Next scan verifies the fix held repeats forever
The improve-security loop: a detective service surfaces a finding, Security Hub normalizes and scores it, an automated action closes it, and the next scan verifies the fix held.

Vulnerability and patch management on a live fleet

Once the loop exists, the highest-volume work is keeping running compute free of known software vulnerabilities. Two services divide the job cleanly: Amazon Inspector finds the vulnerable software, and AWS Systems Manager Patch Manager fixes the operating-system and application packages.

Amazon Inspector: continuous, no scan windows

Amazon Inspector continuously and automatically scans Amazon EC2 instances, Amazon ECR container images, and AWS Lambda functions[7] for known CVEs and unintended network reachability. There are no scheduled scan jobs to manage; it re-scans whenever inventory changes or a new CVE is published. Mechanics worth knowing for the exam:

  • EC2 scanning runs in hybrid mode by default: agent-based through the SSM agent, or agentless via EBS snapshots[7] of instances that lack the agent, covering OS and programming-language package CVEs plus network-reachability findings.
  • ECR scanning converts repositories to enhanced scanning and continues to monitor each image for 90 days by default[7], re-scanning active images as new CVEs land.
  • Lambda standard scanning inspects function and layer dependencies for CVEs; optional Lambda code scanning additionally evaluates the application code itself.

The product is now simply Amazon Inspector: the legacy 'v2' suffix has been dropped[17]. Critically, Inspector finds CVEs, not malware on disk: choosing Inspector to detect malware on a compromised host is wrong (see the next section).

Patch Manager: baselines, compliance, and maintenance windows

AWS Systems Manager Patch Manager[14] defines patch baselines (auto-approval rules by classification, severity, and an approval delay), scans managed instances for missing OS and application patches, reports patch compliance fleet-wide, and installs approved patches on a schedule via maintenance windows. It is the SAP-C02 answer whenever the requirement is 'keep hundreds of instances patched and prove compliance' with the least operational overhead, not building a custom patch pipeline.

Wire the two together

The self-healing pattern is: Inspector raises a CVE finding → it flows into Security Hub via ASFF → an EventBridge rule (or a Security Hub automation rule plus EventBridge) triggers an SSM Automation document or a Patch Manager maintenance-window run that patches the affected instances, then the next Inspector scan verifies the CVE is gone. The figure below traces that chain end to end. For containers, the same finding should instead drive a rebuild of the base image in your CI pipeline, because patching a running container in place is an anti-pattern.

Amazon Inspector raises CVE finding AWS Security Hub via ASFF EventBridge rule triggers remediation SSM Automation or Patch Manager run patches instances Next Inspector scan verifies CVE is gone
Vulnerability self-healing: Inspector raises a CVE finding, Security Hub normalizes it, EventBridge triggers an SSM/Patch Manager fix, then a re-scan verifies.

Threat response, credential hardening, and data protection

Beyond patching, improving an existing workload means responding to live threats, removing the credentials an attacker would steal, and tightening protection on the data already stored. The figure below groups the work into those three pillars and the services under each.

Tune threat detection into automated response

Amazon GuardDuty continuously analyzes three foundational data sources: CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs[5] (with optional protection plans adding S3 data events, EKS, RDS login activity, Lambda network activity, and Malware Protection) to find active threats: compromised credentials, reconnaissance, crypto-mining. Improving response means routing GuardDuty findings through EventBridge to an automated containment runbook (isolate the instance's security group, revoke a session, snapshot for forensics) rather than emailing an analyst. When a finding suggests malware, GuardDuty Malware Protection runs an agentless scan of the EBS volumes attached to the suspect EC2 instance[6]; a GuardDuty-initiated scan launches automatically (at most once per 24 hours per resource) and snapshots are retained only when malware is found. Malware detection is GuardDuty's job, not Inspector's.

Eliminate long-lived credentials

The single biggest attack-surface reduction on an existing workload is deleting static IAM user access keys and replacing them with short-lived credentials. Compute should assume an IAM role (instance profile, ECS task role, Lambda execution role) so the SDK fetches and rotates temporary STS credentials automatically; workforce humans should sign in through IAM Identity Center instead of holding IAM users. Audit which permissions and credentials are actually exercised using IAM service and action last-accessed data[11] and the account credential report, and flag idle roles and users with IAM Access Analyzer unused-access findings. The pricing split is exam-tested: external-access findings (public and cross-account access) are free, while unused-access analysis is billed per IAM role or user analyzed per month[12]. Remember a permissions boundary, like an SCP, only filters and never grants[13]: it caps an over-privileged identity but cannot widen it.

For credentials that must persist (database and third-party secrets), eliminate manual rotation with AWS Secrets Manager managed rotation[15]: no Lambda for Aurora, RDS, Amazon DocumentDB, and Amazon Redshift; custom secrets still need a rotation Lambda implementing the four-step contract. Managed rotation supersedes the old per-engine rotation-Lambda pattern.

Protect the data already at rest

Find sensitive data before an attacker does: Amazon Macie uses managed and custom data identifiers[8] to discover and classify PII, financial data, and credentials in Amazon S3, runs continuous automated sensitive-data discovery plus targeted discovery jobs, and reports each bucket's public-access and encryption posture, publishing to EventBridge and Security Hub. Macie is S3-only; it does not scan RDS, DynamoDB, or EBS. Reduce data exposure by turning on S3 Block Public Access[18] at the account level (its four settings, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets, combine so S3 enforces the most restrictive of account- and bucket-level settings, and it satisfies FSBP control S3.8), enforcing default encryption, and rotating customer-managed KMS keys. Note that scheduling deletion of a customer-managed KMS key enforces a mandatory 7-to-30-day waiting period, default 30 days[19], so key cleanup is deliberate, never instant.

Threat response Amazon GuardDuty GuardDuty Malware Protection Credential hardening IAM roles / Identity Center IAM Access Analyzer Secrets Manager Data protection Amazon Macie S3 Block Public Access AWS KMS
Three pillars of improving a live workload: threat response (GuardDuty), credential hardening (IAM, Secrets Manager), and data protection (Macie, S3 BPA, KMS).

Self-healing compliance and attack-surface reduction

The most-tested improve-security pattern is turning configuration drift into self-healing: AWS Config detects the non-compliant state and an SSM Automation document fixes it with no human in the loop.

Config rule + SSM Automation = auto-remediation

AWS Config applies remediation using AWS Systems Manager Automation documents[3]; you associate a managed or custom SSM document with a Config rule and choose manual or automatic remediation. With auto-remediation[20], if a resource is still non-compliant after the action runs you can configure retries within a time window (for example, 5 retries in 300 seconds). Canonical remediations: re-enable S3 default encryption, re-apply S3 Block Public Access, or revoke a security-group rule that opened 0.0.0.0/0. The recurring distractor is to have Config merely notify a human; the professional answer attaches the SSM Automation remediation so the fix is automatic. The diagram below traces that chain: a non-compliant resource trips an AWS Config rule, whose remediation action runs an SSM Automation document that fixes the resource so Config re-evaluates it as COMPLIANT.

Reduce the attack surface of running instances

Harden the metadata endpoint: require IMDSv2[21], the session-oriented PUT-token method that adds defense in depth against SSRF, open firewalls, and reverse-proxy attacks that would otherwise let an attacker read the instance role's credentials. You can set HttpTokens=required on existing instances with modify-instance-metadata-options (and keep the default response hop limit of 1), then enforce it fleet-wide with a Config rule plus auto-remediation. Pair this with last-accessed-driven least privilege so even a stolen role grants little.

Exam-pattern recognition

Match the stem's verb and object to the one service:

  • "AWS Config flags S3 buckets without encryption across the org; fix them automatically with no manual steps." → Config rule + SSM Automation auto-remediation. Distractors: an EventBridge-to-SNS notification (detects, never fixes); a one-off Lambda that does not re-run on new buckets.
  • "Continuously detect unpatched CVEs in EC2 and container images as inventory changes, no scan schedule." → Amazon Inspector. Distractors: GuardDuty (threats, not CVEs); Macie (S3 data); a manual Inspector 'assessment run' (that is the retired classic Inspector behavior).
  • "A GuardDuty finding indicates possible malware on an instance; confirm it." → GuardDuty Malware Protection (agentless EBS scan). Distractor: Amazon Inspector; it finds CVEs, not malware.
  • "Patch hundreds of instances on a schedule and report compliance." → Systems Manager Patch Manager with baselines + maintenance windows. Distractor: a hand-rolled patch script per instance.
  • "Find and remove unused IAM roles, permissions, and stale credentials across 200 accounts." → IAM Access Analyzer unused-access + last-accessed data. Distractors: Macie (S3 data, not IAM); GuardDuty (active threats, not dormant entitlements).
  • "Rotate the production database password regularly with no custom code." → Secrets Manager managed rotation (RDS/Aurora/DocumentDB/Redshift). Distractor: a hand-written rotation Lambda (the legacy pattern).
  • "Discover where PII is stored in our S3 estate." → Amazon Macie. Distractors: GuardDuty / Inspector (wrong layer); Macie cannot scan RDS or DynamoDB.
  • "After a credential-compromise alert, determine the full blast radius from log history." → Amazon Detective behavior graph. Distractor: Security Hub (aggregates findings, does not investigate).
  • "Aggregate GuardDuty, Inspector, and Macie findings into one console with a CIS/PCI score org-wide." → AWS Security Hub (ASFF + central configuration). Distractor: Detective (investigation, not aggregation/scoring).

The meta-pattern: if the requirement is to block an action before it happens, that is a preventive guardrail in security-controls; everything here is about detecting, remediating, and hardening what already runs.

Non-compliant resource drift detected AWS Config rule s3-bucket-server-side- encryption-enabled Remediation action SSM Automation document Resource fixed re-evaluated COMPLIANT next evaluation re-checks the rule
AWS Config auto-remediation: a non-compliant resource trips a Config rule whose remediation runs an SSM Automation document, fixing the resource so it re-evaluates COMPLIANT.

Choosing the security service for continuous improvement of an existing workload

DimensionAmazon GuardDutyAmazon InspectorAmazon MacieAWS Security HubAmazon Detective
Primary jobThreat detection from logs/telemetryContinuous vulnerability (CVE) scanningSensitive-data discoveryPosture aggregation + standards scoreInvestigate / root-cause a finding
InputsCloudTrail, VPC Flow Logs, DNS (+S3/EKS/RDS/Lambda, malware)EC2, ECR images, Lambda functionsAmazon S3 objectsASFF findings from other servicesCloudTrail, VPC Flow Logs, EKS audit logs
OutputThreat findings (IOCs, recon, crypto-mining)Vulnerability + network-reachability findingsSensitive-data + bucket-policy findingsAggregated findings + security scoreBehavior graph + entity profiles
Continuous?Yes (always-on)Yes (event-driven on inventory change)Scheduled + automated discovery jobsYes (ingests continuously)Yes (graph kept current)
Consumes other services?No (a source)No (a source)No (a source)Yes: ingests GuardDuty/Inspector/Macie/Access AnalyzerYes: starts from GuardDuty/Security Hub findings
Typical exam answerDetect compromised credentials / crypto-miningFind unpatched CVEs in EC2/containersFind unencrypted PII in S3Single console + compliance score org-wideDetermine blast radius of a finding

Decision tree

What is the security gap you must close? Active threat / IOC Detect or investigate the threat? Drift / non-compliant config Resource config or OS patch level? Excess access / data risk Identity access or sensitive data? Detect Amazon GuardDuty + Malware Protection Investigate Amazon Detective graph from findings Config AWS Config rule + auto-remediation SSM Automation document Patch / vuln Amazon Inspector + SSM Patch Manager Access IAM Access Analyzer unused + external Data Amazon Macie sensitive data in S3 Always: aggregate every finding in AWS Security Hub (ASFF), drive remediation via EventBridge to SSM Automation or Lambda
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.

Security Hub aggregates findings via ASFF, not its own detector

AWS Security Hub is the single pane of glass: it ingests GuardDuty, Inspector, Macie, and IAM Access Analyzer findings normalized into the AWS Security Finding Format (ASFF) and scores posture against standards like AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, NIST SP 800-53, and PCI DSS. It correlates and prioritizes findings from many sources but is not itself a threat detector: the detection happens in the services that feed it.

Trap Treating Security Hub as the detector that finds threats, rather than the aggregator that consolidates other services' findings.

1 question tests this
Security Hub automation rules transform or suppress findings on arrival

Security Hub automation rules let the administrator account auto-update finding fields (severity, workflow status, notes) or suppress matching findings the moment they are ingested, before they flow on to EventBridge or a ticketing system. Rules apply across the admin account and all member accounts, and central configuration pushes standards and controls to OUs and accounts org-wide. The catch: a rule applies only in the Region where it is created, so org-wide action needs the rule replicated in every Region (e.g. via CloudFormation).

Trap Assuming one automation rule covers every Region: rules are Regional and must be recreated per Region.

1 question tests this
GuardDuty detects threats from logs, not from configuration

Amazon GuardDuty continuously analyzes three always-on foundational sources at no extra cost (CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs) to surface active threats like compromised credentials, reconnaissance, and crypto-mining. CloudTrail S3 data events, EKS runtime, RDS login activity, Lambda network activity, and malware scanning are optional protection plans, not foundational. GuardDuty is detective and always-on; it reads logs and never changes configuration.

Trap Listing CloudTrail S3 data events as a foundational GuardDuty source: they require enabling the optional S3 Protection plan.

GuardDuty Malware Protection finds malware; Inspector finds CVEs

GuardDuty Malware Protection runs the agentless EBS-volume scan (automatically when a GuardDuty finding suggests compromise, or on demand) and can also scan objects on upload to S3. Amazon Inspector, by contrast, scans for software vulnerabilities (CVEs), not malware. When a question asks how to detect malware on a host, the answer is GuardDuty Malware Protection.

Trap Reaching for Amazon Inspector to detect malware on an instance: Inspector reports CVEs and network exposure, not malware.

Inspector continuously scans EC2, ECR, and Lambda for CVEs

Amazon Inspector automatically discovers and continuously scans EC2 instances, ECR container images, and Lambda functions for known CVEs and unintended network exposure, re-scanning whenever a package, patch, or newly published CVE changes the risk. There are no assessment scans to schedule and no agents to babysit. (The product is now just 'Amazon Inspector', the 'v2' suffix was dropped.)

Trap Scheduling periodic Inspector assessment runs: modern Inspector scans continuously and auto-rescans on change, with nothing to schedule.

Macie discovers sensitive data in Amazon S3 only

Amazon Macie uses managed and custom data identifiers (ML plus pattern matching) to discover and classify sensitive data such as PII in Amazon S3, and it reports each bucket's public-access and encryption posture. Its scope is Amazon S3: it does not inspect RDS, DynamoDB, or EBS, so for sensitive data in those stores Macie is the wrong answer.

Trap Choosing Macie to classify sensitive data in RDS, DynamoDB, or EBS: Macie only analyzes Amazon S3.

Access Analyzer external findings are free; unused-access analysis is billed

IAM Access Analyzer external-access findings (public and cross-account access to your resources, found by automated reasoning on resource policies) carry no additional charge. Unused-access analysis, which flags unused roles, users, access keys, passwords, and permissions over a tracking window, is billed per IAM role or user analyzed per analyzer per month. It is neither entirely free nor entirely paid: the split is the testable point.

Trap Assuming all of IAM Access Analyzer is free: unused-access (and internal-access) analyzers are paid per resource analyzed.

Audit least privilege with last-accessed data plus unused-access findings

To right-size existing permissions, pair IAM service/action last-accessed data and the account credential report (to expose unused permissions and stale credentials) with IAM Access Analyzer unused-access findings (to flag idle roles, users, keys, and passwords). Remove what is never exercised rather than guessing: last-accessed evidence is also what AWS recommends for refining over-broad SCPs.

Trap Trusting service last-accessed data to scope resource-level permissions, since it tracks access only at the service and action level, not per individual resource.

1 question tests this
Config rules plus SSM Automation give you self-healing remediation

AWS Config rules detect non-compliant resources and can trigger an automatic remediation backed by an SSM Automation document (for example re-enabling S3 Block Public Access or revoking an open security-group rule) turning drift detection into self-healing without human action. Remediation always runs an SSM Automation document, so the fix is whatever that runbook does.

Trap Wiring a Config remediation action straight to a Lambda function, when Config remediation invokes an SSM Automation document, so a Lambda fix has to be wrapped in a runbook.

6 questions test this
EventBridge routes findings to automated remediation

The prescribed automated-response pattern routes findings from Security Hub, GuardDuty, or Config through Amazon EventBridge rules to an AWS Lambda function or an SSM Automation document, so detection triggers a fix instead of a ticket. Favor this automated path over manual handling when a question contrasts automated remediation with human investigation.

3 questions test this
Patch Manager reports and remediates fleet patch compliance

AWS Systems Manager Patch Manager defines patch baselines, runs a Scan to report missing OS and application patches, or Scan-and-install to apply them, and surfaces fleet-wide patch compliance. It installs on a schedule via maintenance windows (or patch policies / on-demand Patch now), and is the SAP-C02 answer for fleet-wide patch compliance and remediation.

Trap Reaching for Amazon Inspector to remediate missing patches, since Inspector only reports vulnerabilities, while Patch Manager actually scans for and installs the patches.

Detective investigates an existing finding; it does not detect

Amazon Detective builds a behavior graph from its three core sources (CloudTrail logs, VPC Flow Logs, and ingested GuardDuty findings) so analysts can pivot from a GuardDuty or Security Hub finding to root cause and blast radius across up to a year of history (EKS audit logs and Security Hub findings are optional add-on source packages). It is for investigation after detection, never a replacement for GuardDuty's detection.

Trap Picking Detective to detect threats: it investigates and visualizes findings that GuardDuty (or another detector) already raised.

Audit Manager automates compliance evidence, not threat detection

AWS Audit Manager continuously collects evidence from your AWS usage and maps it to prebuilt frameworks (CIS, PCI DSS, SOC 2, GDPR, HIPAA) to streamline audits and produce assessment reports. It produces audit-ready evidence: it does not detect threats or remediate, and it does not itself certify your compliance.

Trap Choosing Audit Manager to detect or block a security threat: it collects compliance evidence, not real-time detection or remediation.

Detective controls only report; preventive guardrails block

GuardDuty, Inspector, Macie, and AWS Config are detective controls: they find and report a problem but cannot stop the action. To actually prevent it, reach for preventive guardrails: service control policies (SCPs) or resource control policies (RCPs) in AWS Organizations, or AWS Firewall Manager policies. An SCP never grants access; it sets the maximum permissions, so naming a detective service to 'block' or 'prevent' something is a wrong answer.

Trap Selecting GuardDuty, Macie, or Config to prevent or block an action: detective controls only report; use an SCP/RCP or Firewall Manager to block.

Security Hub cross-Region aggregation funnels findings to one home Region

Enable cross-Region aggregation in the Security Hub delegated-admin account by designating a home (aggregation) Region and linking the others; findings, finding updates, insights, control compliance statuses, and security scores from linked Regions then surface in the home Region at no extra cost. Build the single downstream integration (e.g. an EventBridge rule to a SIEM) in the home Region so it sees all linked Regions. Automation rules stay Regional, so to act on findings everywhere you still replicate the rule in each Region.

Trap Expecting a home-Region automation rule to act on aggregated findings from every linked Region: aggregation centralizes the view, not rule execution.

11 questions test this
Suppress duplicate global GuardDuty findings outside the aggregation Region

Credential-related GuardDuty findings (Resource Type AccessKey, driven by global CloudTrail management events) replicate across Regions and look duplicated after Security Hub cross-Region aggregation. A GuardDuty suppression rule auto-archives new findings that match its criteria (and in a multi-account org only the GuardDuty administrator can create them). Create the suppression rules in every Region except the Security Hub home/aggregation Region, so the duplicates are archived elsewhere while the canonical finding stays visible in the home Region.

Trap Creating the suppression rule in the home/aggregation Region: that archives the copy you wanted to keep visible.

6 questions test this
KMS automatic rotation keeps old key material and never re-encrypts data

Automatic rotation of a KMS customer managed key generates new key material but retains all previous key material, so existing ciphertext stays decryptable and your data is not re-encrypted: rotation changes only the current key material, and to truly re-key data you must re-encrypt it yourself. The rotation period defaults to 365 days and is configurable, with on-demand rotation also available. Automatic rotation works only on symmetric keys with AWS_KMS-generated material; keys with imported (EXTERNAL) material can't auto-rotate and are rotated on demand after you import new material.

Trap Believing KMS key rotation re-encrypts existing data: it only swaps the current key material; old material is kept so prior ciphertext still decrypts.

4 questions test this
Organization conformance packs deploy a Config rule set across the org

A conformance pack is a collection of AWS Config rules and remediation actions deployed as one entity; as an organization conformance pack from the management or delegated-admin account, it enforces a baseline across all member accounts. Each member account needs a working Config recorder for its rules to evaluate, and the pack reports compliant only when every evaluated rule is compliant.

Trap Expecting conformance-pack rules to evaluate in a member account that has no Config recorder turned on.

9 questions test this
Config auto-remediation runs SSM Automation and needs a per-account role

AWS Config automatic remediation invokes an SSM Automation document using an AutomationAssumeRole that must already exist with the right permissions in each target account, including across an organization. Because remediation relies on the periodic compliance-data snapshot, a resource changed between snapshots can be remediated on stale data (auto-remediation can even fire on a now-compliant resource) and PutRemediationExceptions exempts specific resources.

Trap Assuming a single central AutomationAssumeRole works org-wide: the role must exist in every target account that gets remediated.

10 questions test this
Network Firewall logs alert/flow/TLS traffic and deploys centrally via Firewall Manager

AWS Network Firewall's stateful engine can emit flow logs, alert logs, and TLS logs, each published to CloudWatch Logs, Amazon S3, or Amazon Data Firehose (formerly Kinesis Data Firehose) for monitoring and analysis (e.g. with Athena/QuickSight). Use AWS Firewall Manager to centrally create and enforce Network Firewall policies across every account and VPC in an organization rather than configuring each firewall by hand.

Trap Reaching for AWS WAF or Shield to filter VPC network traffic, since those guard application-layer and DDoS at the edge, while stateful VPC traffic inspection is Network Firewall's job.

6 questions test this

Also tested in

References

  1. AWS Security Finding Format (ASFF)
  2. Security Hub automation rules
  3. Remediating noncompliant resources with AWS Config rules
  4. What is Amazon Detective?
  5. How Amazon GuardDuty uses its data sources
  6. GuardDuty Malware Protection
  7. Scanning Amazon Inspector resources
  8. What is Amazon Macie?
  9. Using IAM Access Analyzer
  10. Evaluating resources with AWS Config rules
  11. Refine permissions using last accessed information
  12. IAM Access Analyzer pricing
  13. IAM JSON policy evaluation logic
  14. AWS Systems Manager Patch Manager
  15. Managed rotation for AWS Secrets Manager
  16. What is AWS Audit Manager?
  17. What is Amazon Inspector?
  18. Blocking public access to your Amazon S3 storage
  19. Deleting AWS KMS keys
  20. Setting up auto remediation for AWS Config
  21. Use the Instance Metadata Service to access instance metadata