Domain 3 of 6 · Chapter 1 of 3

Edge Security

The edge protection stack, layer by layer

A request to a public AWS app passes through three independent controls before it reaches your origin, and each one judges a different property of the request. Amazon CloudFront[1] is the content delivery network at the front: it terminates TLS at the edge location nearest the viewer, caches responses, and forwards cache misses to the origin. AWS Shield[2] sits with CloudFront and absorbs distributed denial-of-service (DDoS) floods at the network and transport layers. AWS WAF[3], a web application firewall, inspects the HTTP and HTTPS requests that survive and decides per request whether to allow, block, count, or challenge them.

Why three controls and not one

The split follows the OSI layer each attack targets. A volumetric DDoS is a layer 3/4 problem: millions of packets, no single one malicious, so the defense is absorption capacity, which is Shield's job. An SQL injection is a layer 7 problem: one crafted request, so the defense is content inspection, which is WAF's job. Caching and TLS termination are delivery concerns, which is CloudFront's job. Trying to make one control do all three would mean inspecting every packet of a flood for SQL syntax, which does not scale. Layering lets each control work at the layer where the signal is cheapest to read.

How they attach

You associate a WAF web ACL (access control list) with the CloudFront distribution, the Application Load Balancer (ALB), the Amazon API Gateway stage, or the AWS AppSync API that fronts your app. Shield Standard applies automatically and free to CloudFront, Amazon Route 53, and AWS Global Accelerator; Shield Advanced is a subscription you add to protected resources. Because WAF and Shield both bind to the same edge resource, a CloudFront distribution can run a web ACL and carry Shield Advanced at once, with no conflict between them.

ViewerinternetAWS ShieldL3/L4 DDoS absorbAWS WAFL7 inspect rulesCloudFrontTLS + cacheOriginon miss
Each edge control judges a different layer: Shield absorbs the flood, WAF inspects the request, CloudFront delivers.

AWS WAF rules: managed groups, rate-based, geo, and labels

AWS WAF protects against the OWASP Top 10[4] application risks through rules you compose in a web ACL, evaluated top to bottom until one terminates the request. The cheapest and broadest defense is the AWS Managed Rules[5], pre-built rule groups AWS maintains so you do not hand-write attack signatures.

The managed rule group families

Baseline groups apply broadly: the Core rule set (CRS, AWSManagedRulesCommonRuleSet) covers the common OWASP risks, Admin protection blocks exposed admin paths, and Known bad inputs catches request patterns tied to exploitation. Use-case groups target a stack: the SQL database group hardens against SQL injection, and there are OS and application-specific groups. IP reputation groups (Amazon IP reputation list, Anonymous IP list) block known-bad and anonymizing sources. A separate tier of intelligent threat mitigation, Bot Control, account takeover prevention (ATP), and account creation fraud prevention (ACFP), carries additional fees because it fingerprints clients rather than matching signatures.

Your own rules on top

Beyond managed groups you add custom statements. A rate-based rule[6] counts requests per aggregation key over a trailing evaluation window of 60, 120, 300, or 600 seconds (default 300), and acts once a key exceeds the limit, whose lowest allowed setting is 10. You choose the aggregation key: source IP, an IP taken from a forwarded header such as X-Forwarded-For, or custom keys, which is the "client fingerprinting" the blueprint names. A geo-match statement filters by country (CountryCodes), an IP set matches address ranges you maintain, and string/regex statements match request components.

Labels chain rules together

A matching rule can attach a label[7] to the request instead of immediately blocking, and a later rule can match that label. This lets you build staged logic, for example let the Bot Control group label a request as a verified bot, then a downstream rule decides whether that category is allowed. Every rule action is one of Allow, Block, Count (observe without acting, the tuning mode), or Captcha/Challenge (issue a token-backed challenge the client must solve).

1. IP set allow / blocktrusted or banned ranges2. Managed rule groupsCRS, Known bad inputs, SQL3. Rate-based rulelimit per key, 300s window4. Geo-match + customcountry, string, regexDefault actionno matchon matchAllowforward to originBlock / Countor Captcha / Challenge
A web ACL evaluates rules in priority order; the first terminating match wins, otherwise the default action applies.

Shield Standard versus Shield Advanced

AWS Shield comes in two tiers, and the exam leans on knowing exactly what the paid tier buys. Shield Standard[2] is automatic and free for every AWS customer, defending CloudFront, Route 53, and Global Accelerator against the common, most frequent network and transport-layer DDoS attacks with no configuration.

What Advanced adds

Shield Advanced[8] is a paid subscription that extends protection to Elastic IP addresses, the Application Load Balancer, Classic Load Balancer, CloudFront, Global Accelerator, and Route 53 hosted zones. It adds four things Standard lacks: 24/7 access to the Shield Response Team (SRT), the AWS experts who help during an active attack; near-real-time attack diagnostics and CloudWatch metrics; automatic application-layer DDoS mitigation, where Shield deploys WAF rules on your behalf during an attack; and DDoS cost protection, which refunds the scaling charges (extra CloudFront data transfer, ALB capacity, EC2 scale-out) you incur because of a covered attack.

The numbers that get tested

Shield Advanced costs $3,000 per month per payer account[9] in an AWS Organization, not per organization and not per protected resource, with a 1-year subscription commitment, plus data-transfer-out fees for protected resources. Subscribe once on the payer (management/consolidated-billing) account and the fee is not multiplied across member accounts under the same payer. Note the team name is the Shield Response Team (SRT); the old name DDoS Response Team (DRT) is retired and should not appear in new content.

When the answer is Advanced

The exam steers you to Advanced when the scenario needs human DDoS support during an incident, a financial guarantee against attack-driven bills, protection on resources Standard does not cover such as an Elastic IP on EC2, or automatic L7 mitigation. If the scenario only needs basic protection on a CloudFront-fronted site and mentions no budget guarantee or SRT, Standard already covers it and Advanced is the over-engineered distractor.

Need SRT, cost protection,or non-CloudFront resource?NoYesShield Standardfree, automatic, L3/L4Shield Advanced$3,000/mo per payer, 1-yrAdvanced includes- 24/7 Shield Response Team (SRT)- automatic L7 mitigation- near-real-time diagnostics- DDoS cost protection refund
Pick Standard unless the scenario needs SRT, cost protection, automatic L7 mitigation, or coverage beyond CloudFront/Route 53/Global Accelerator.

Locking the origin: OAC, response headers, and CORS

WAF only protects what funnels through it, so an attacker who reaches the origin directly bypasses every rule. The fix is to make the origin reachable only through CloudFront. Origin access control (OAC)[10] signs each request CloudFront sends to an Amazon S3 origin with SigV4, and the bucket policy then permits only that distribution and denies everyone else. OAC supersedes the legacy origin access identity (OAI) and supports SSE-KMS encrypted objects and all AWS Regions.

Security response headers

CloudFront can attach security headers to every response through a response headers policy[11], so you do not rebuild this on each origin. The policy can set HTTP Strict Transport Security (HSTS) to force HTTPS, X-Content-Type-Options: nosniff to stop MIME sniffing, X-Frame-Options to block clickjacking, and a Content-Security-Policy. These travel back to the browser and harden the client side of the application.

Cross-origin resource sharing

S3 CORS[12] is a browser security control, not a server firewall: it tells the browser which other origins may read responses from your bucket via JavaScript. You configure AllowedOrigins, AllowedMethods, and AllowedHeaders on the bucket. CORS only relaxes the browser's same-origin policy for the origins you list; it never grants AWS-level access, so it is not an authorization mechanism and a permissive * origin is a finding, not a convenience.

Exam pattern recognition

A stem describing "users can reach the S3 bucket URL directly and skip the WAF rules" points to OAC plus a restrictive bucket policy. A stem about "the browser blocks the front-end from calling the API on another domain" points to CORS, not IAM or a security group. A stem asking to "enforce HTTPS and prevent clickjacking from the CDN" points to a CloudFront response headers policy. Confusing CORS (a browser read-permission list) with an authorization control is the classic trap here.

ViewerHTTPSCloudFront + WAFOAC signs (SigV4)signedS3 originprivate bucketDirect bucket URL: denied by bucket policy
OAC lets only the distribution reach the private S3 bucket; a direct viewer hit on the bucket URL is denied, so WAF cannot be bypassed.

Integrating outside data and rules: OCSF and third-party WAF

The C03 exam adds edge integrations that cross the AWS boundary in both directions, so know what each one carries. Going out, Amazon Security Lake[13] centralizes security data, including AWS WAF logs, into a data lake in your own S3 and converts it into the Open Cybersecurity Schema Framework (OCSF)[14] stored as Apache Parquet. OCSF is a vendor-neutral schema, so a third-party SIEM or analytics tool queries one normalized format instead of parsing each source's native log shape, and subscribers read the data through Amazon Athena, Amazon Redshift, or AWS Lake Formation.

Why OCSF matters at the edge

WAF emits detailed logs of every inspected request, but in its native JSON. Normalizing to OCSF means a downstream tool correlates a WAF block with a VPC Flow Log or a CloudTrail event using shared field names, which is the whole point of "ingesting data in OCSF format" that the blueprint calls out. Security Lake collects WAFv2 logs natively, alongside CloudTrail, Route 53 resolver query logs, VPC Flow Logs, EKS audit logs, and Security Hub findings, and can take custom sources you map into OCSF.

Third-party WAF rules

Going the other way, you do not have to write or rely solely on AWS rules. The AWS Marketplace offers managed rule groups[15] from third-party security vendors (for example F5, Fortinet, Imperva), and you subscribe to one and reference it in your web ACL exactly like an AWS managed group. They evaluate in priority order alongside AWS groups and your custom rules, so you can combine a vendor's specialized signatures with the AWS Core rule set in one policy.

Exam pattern recognition

A stem about "ingest security findings from multiple AWS and third-party tools into one queryable schema" points to Security Lake with OCSF, not to raw S3 logging or a manual ETL pipeline. A stem about "apply a specific commercial vendor's WAF ruleset" points to a Marketplace managed rule group, not to rebuilding those signatures as custom AWS WAF rules.

Out: telemetry to OCSFAWS WAF logs+ CloudTrail, VPC FlowSecurity LakeOCSF + Parquet in S3SIEM subscriberAthena / Redshift queryIn: third-party rules to the edgeMarketplace rule groupvendor managed signaturessubscribeWeb ACL+ AWS groups + custom
Edge integrations cross the AWS boundary both ways: telemetry out to OCSF in Security Lake, vendor rule groups in from the Marketplace.

Edge protection layers: what each one inspects and stops

PropertyCloudFrontAWS WAFAWS Shield
OSI layerL3-L7 delivery / TLSL7 HTTP/HTTPSL3/L4 (Standard), +L7 (Advanced)
Primary jobCaching, TLS, request routingFilter app-layer attacksAbsorb / mitigate DDoS
StopsOrigin overload, latencyOWASP Top 10, bots, rate floodsVolumetric / protocol DDoS
Cost modelPer request + data transferPer web ACL + rule + requestStandard free; Advanced $3,000/mo per payer
Key controlOAC, response headers policyManaged + rate-based + geo rulesSRT access, cost protection (Advanced)

Decision tree

Application-layer (L7)attack or abuse?Yes (OWASP, bots, floods)NoAWS WAF web ACLCRS + rate-based + geo rulesVolumetric / protocol DDoS risk?Need SRT / cost protectionBaseline onlyShield Advanced$3,000/mo per payer, SRT, refundShield Standardfree, automatic, L3/L4Always: CloudFront front door with OAC to a private origin,security response-headers policy, and CORS scoped to known origins
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.

Layer the edge: CloudFront for delivery, WAF for L7, Shield for DDoS

An internet-facing app gets layered protection where each control works at a different OSI layer: CloudFront terminates TLS and caches, AWS WAF inspects HTTP/HTTPS requests for application-layer attacks, and AWS Shield absorbs L3/L4 DDoS floods. They stack on the same edge resource rather than compete, so one CloudFront distribution can carry both a WAF web ACL and Shield at once. Match the control to the layer the attack targets: a volumetric flood is absorption (Shield), a crafted request is inspection (WAF).

Trap Reaching for a security group or NACL to stop an OWASP-style web attack; those filter at L3/L4 inside the VPC and never inspect HTTP request content the way a WAF web ACL does.

WAF is the OWASP Top 10 control, delivered through managed rule groups

AWS WAF defends against the OWASP Top 10 web risks (injection, broken access control, and the rest) through AWS Managed Rules, pre-built rule groups you enable instead of hand-writing signatures. The baseline Core rule set (CRS, AWSManagedRulesCommonRuleSet) covers the broad common attacks, while Known bad inputs and the SQL database group target specific classes. Managed groups are maintained by AWS and updated as new threats emerge, so they are the first reach for generic web protection.

Trap Writing custom string/regex rules to reproduce SQL-injection or XSS protection AWS already ships; the AWS managed Core rule set and SQL database group cover the OWASP classes and stay maintained for you.

1 question tests this
Web ACL rules evaluate in priority order; first terminating match wins

A web ACL runs its rules from lowest to highest priority number and stops at the first rule whose action terminates evaluation. Each rule action is Allow, Block, Count, or Captcha/Challenge: Allow and Block are terminating, Count only tallies and lets evaluation continue (the safe tuning mode), and Challenge issues a token-backed test. If no rule matches, the web ACL's default action (Allow or Block) decides.

Trap Assuming Count blocks traffic; Count is observe-only, used to test a rule's match volume before switching it to Block, so a rule left on Count stops nothing.

2 questions test this
Rate-based rules throttle per key over a 60/120/300/600s window

A WAF rate-based rule counts requests per aggregation key over a trailing evaluation window of 60, 120, 300, or 600 seconds, defaulting to 300 (5 minutes), and acts on a key once it exceeds the limit. The lowest rate limit you can set is 10 requests, and WAF looks back over the window continuously rather than resetting on a fixed schedule. This is the standard defense against HTTP floods and brute-force bursts when no signature matches.

Trap Treating the evaluation window as a fixed bucket that resets every N seconds; WAF re-estimates the rate frequently over a rolling look-back, so a client cannot dodge it by timing requests to a window boundary.

1 question tests this
Choose the rate-based aggregation key, including custom client fingerprinting

A rate-based rule aggregates by source IP by default, but you can aggregate by an IP pulled from a forwarded header such as X-Forwarded-For (use this when CloudFront or a proxy fronts the app so the real client IP survives), or by custom keys built from headers, cookies, or query strings. Custom-key aggregation is the "client fingerprinting" the blueprint names: it lets you rate-limit per session token or per API key rather than per IP.

Trap Aggregating on source IP alone behind CloudFront, which collapses many clients onto the CDN's edge IPs; use IP-in-header (X-Forwarded-For) so the rate limit tracks the true viewer.

1 question tests this
Geo-match and IP sets filter by country and address range at the edge

A geo-match statement blocks or allows requests by country code (CountryCodes), and an IP set is a reusable list of CIDR ranges a rule references to allow trusted sources or block known-bad ones. Both run in the same web ACL as your managed and rate-based rules, so you enforce geography and IP allow/deny lists at the edge before traffic reaches the origin. Geo-match reads the request's resolved country, not a self-declared header.

Trap Believing geo-match guarantees a user's location; it maps the connecting IP to a country, so a VPN or proxy in another country defeats it, making geo-blocking a coarse control rather than strong access enforcement.

1 question tests this
WAF labels let one rule's match drive a later rule

A matching WAF rule can attach a label to the request instead of terminating, and a downstream rule can match that label to make a combined decision. This builds staged logic, for example letting the Bot Control group label a request as a verified or known bot, then a later rule decides whether that bot category is permitted. Labels turn a flat rule list into composable detection without duplicating match conditions.

1 question tests this
Bot Control, ATP, and ACFP are paid intelligent-threat rule groups

Most AWS managed rule groups are free with WAF, but the intelligent threat mitigation tier carries additional fees because it fingerprints and challenges clients rather than matching signatures: Bot Control (automated traffic), account takeover prevention (ATP, credential-stuffing on login), and account creation fraud prevention (ACFP, fake-signup abuse). Reach for these when the threat is automation or credential abuse, not a payload pattern, and budget for the extra cost.

Trap Assuming every AWS managed rule group is free; Bot Control, ATP, and ACFP add per-request fees on top of base WAF charges, so enabling them blindly can surprise the bill.

Captcha and Challenge actions verify clients with tokens

Beyond Allow/Block/Count, WAF offers Captcha and Challenge actions that interrupt a suspicious request and require the client to prove it is a real browser. Captcha shows a puzzle to a human; Challenge runs a silent background check (a token-backed JavaScript challenge) with no user interaction. Both issue a token the client presents on later requests, which is why they pair with Bot Control to slow automated clients without blocking legitimate users outright.

Shield Standard is free and automatic on CloudFront, Route 53, Global Accelerator

AWS Shield Standard protects every customer at no cost and with no configuration, defending against the common, most frequent network and transport-layer (L3/L4) DDoS attacks. It applies automatically to CloudFront, Amazon Route 53, and AWS Global Accelerator, so an app fronted by CloudFront already has baseline DDoS coverage. Standard does not include the Shield Response Team, attack diagnostics, or cost protection.

1 question tests this
Shield Advanced is $3,000/mo per payer account with a 1-year commitment

Shield Advanced is a paid subscription priced at $3,000 per month per payer account in an AWS Organization, with a 1-year commitment, plus data-transfer-out fees for protected resources. Because the fee is per payer (the management/consolidated-billing account), you subscribe once and it is not multiplied across every member account under that payer. The cost is the same whether you protect one resource or many.

Trap Reading the price as $3,000 per organization or per protected resource; it is $3,000 per month per payer account, so consolidating accounts under one payer is what keeps the fee from multiplying.

Shield Advanced buys SRT, cost protection, and automatic L7 mitigation

Shield Advanced adds four things Standard lacks: 24/7 access to the Shield Response Team (SRT) for help during an active attack, near-real-time attack diagnostics and metrics, automatic application-layer DDoS mitigation where Shield deploys WAF rules on your behalf, and DDoS cost protection that refunds the scaling charges (extra data transfer, ALB capacity, EC2 scale-out) caused by a covered attack. It also extends coverage to Elastic IPs, ALB, CLB, and Route 53 hosted zones.

Trap Picking Shield Standard when the scenario needs human support during an attack or a refund for attack-driven scaling bills; only Advanced includes the SRT and DDoS cost protection.

4 questions test this
Use the name Shield Response Team (SRT), not DDoS Response Team

AWS renamed the DDoS Response Team to the Shield Response Team (SRT), the experts a Shield Advanced subscriber can engage 24/7 during a DDoS event. Use SRT in current content; the old DRT name is retired and a distractor that says DRT is using stale terminology.

Origin access control (OAC) makes the S3 origin reachable only via CloudFront

OAC signs each request CloudFront sends to an S3 origin with SigV4, and the bucket policy then permits only that distribution and denies direct access, so an attacker cannot bypass WAF by hitting the bucket URL. OAC is the current mechanism and supersedes the legacy origin access identity (OAI); unlike OAI it supports SSE-KMS encrypted objects and all Regions. Without it, a public bucket lets traffic skip the entire edge stack.

Trap Using the legacy origin access identity (OAI) for a new distribution serving SSE-KMS objects; OAI does not support KMS-encrypted origins, so OAC is the correct current choice.

Set security response headers with a CloudFront response headers policy

A CloudFront response headers policy attaches security headers to every response without changing the origin: HSTS to force HTTPS, X-Content-Type-Options: nosniff to stop MIME sniffing, X-Frame-Options to block clickjacking, and a Content-Security-Policy. Centralizing them at the distribution means one policy hardens the browser side across all origins behind it, rather than re-implementing headers on each backend.

S3 CORS is a browser read-permission list, not an authorization control

Cross-origin resource sharing (CORS) on an S3 bucket tells the browser which other origins may read responses via JavaScript, configured through AllowedOrigins, AllowedMethods, and AllowedHeaders. It only relaxes the browser's same-origin policy for the origins you list and grants no AWS-level access, so it never replaces IAM or a bucket policy. A wildcard * origin is a misconfiguration finding, not a convenience.

Trap Treating CORS as an access-control or authorization mechanism; it is a browser-side read-permission hint, so loosening it to * exposes responses to any site's scripts without changing who can authenticate to the bucket.

Security Lake normalizes WAF and other logs to OCSF in Parquet

Amazon Security Lake centralizes security data, including AWS WAF logs, into a data lake in your own S3 and converts it to the Open Cybersecurity Schema Framework (OCSF) stored as Apache Parquet. OCSF is a vendor-neutral schema, so a third-party SIEM queries one normalized format and correlates a WAF block with a VPC Flow Log or CloudTrail event by shared field names. Subscribers read the data through Athena, Redshift, or Lake Formation rather than parsing each source's native log shape.

Trap Building a custom ETL pipeline to merge findings from many AWS and third-party tools into one schema; Security Lake already normalizes to OCSF in Parquet, which is the intended answer for unified, queryable security data.

1 question tests this
Subscribe to third-party WAF rule groups from the AWS Marketplace

You do not have to author every WAF rule: the AWS Marketplace offers managed rule groups from third-party vendors (such as F5, Fortinet, Imperva) that you subscribe to and reference in a web ACL exactly like an AWS managed group. They evaluate in priority order alongside AWS groups and your custom rules, so you can combine a vendor's specialized signatures with the AWS Core rule set in one policy.

Trap Re-implementing a commercial vendor's WAF signatures as custom AWS rules; subscribing to that vendor's Marketplace managed rule group is the supported path and keeps the signatures vendor-maintained.

1 question tests this
WAF inspects only HTTP/HTTPS, so non-web protocols need other controls

AWS WAF is a web application firewall: it only inspects layer-7 HTTP and HTTPS requests on the resources a web ACL attaches to (CloudFront, ALB, API Gateway, AppSync). Raw TCP/UDP services, or attacks below L7, fall outside WAF entirely and rely on Shield for DDoS plus VPC controls like security groups and Network Firewall. Knowing this boundary keeps you from proposing a web ACL for a non-HTTP workload.

Trap Proposing a WAF web ACL to protect a non-HTTP service (such as a custom TCP listener on an NLB); WAF inspects only HTTP/HTTPS, so that traffic needs Shield and VPC-layer controls instead.

Attach a single web ACL to CloudFront, ALB, API Gateway, or AppSync

A WAF web ACL associates with CloudFront distributions (global scope), or with regional resources: an Application Load Balancer, an Amazon API Gateway stage, an AWS AppSync GraphQL API, a Cognito user pool, or an App Runner service. CloudFront web ACLs use the CLOUDFRONT scope in us-east-1; regional web ACLs are created in the resource's own Region. Front the app at the outermost internet-facing resource so WAF sees traffic before it fans in.

3 questions test this
Security Lake custom sources must be OCSF Parquet partitioned by region/accountId/eventDay

A Security Lake custom source must deliver OCSF-conformant Apache Parquet objects written under its assigned prefix with the partition layout region=/accountId=/eventDay=/ (eventDay has no separators). This partitioning is what lets the source's Glue crawler register partitions for Athena pruning. Deliver each distinct OCSF event class as its own custom source, and run the source's Glue crawler when the schema gains fields.

Trap Pushing raw JSON or a single mixed-class feed — each OCSF event class needs its own custom source in Parquet with the region/accountId/eventDay partitions.

6 questions test this
A Security Lake data-access subscriber reads OCSF objects from S3 via an SQS/HTTPS notification and external ID

A data-access subscriber reads OCSF Parquet objects directly from the Security Lake S3 bucket: Security Lake provisions a subscriber IAM role and an SQS queue (or HTTPS endpoint) so the consumer is notified of new objects and assumes the role to read them. You supply the partner account ID and a unique external ID, which Security Lake enforces as an sts:ExternalId condition on every AssumeRole.

Trap Choosing query (Lake Formation/Athena) access when the consumer must read raw S3 objects without Athena — that requires data access, not query access.

3 questions test this
Cross-account Security Lake readers need kms:Decrypt in the data-lake key policy

When the Security Lake bucket is encrypted with a customer-managed KMS key in the delegated-administrator account, any cross-account principal that reads or writes objects (a subscriber role on GetObject, a Glue crawler, or a collector on PutObject) must be granted kms:Decrypt and kms:GenerateDataKey in that key's policy, not just in its identity policy. ListBucket can succeed while GetObject fails with a KMS AccessDenied when this is missing; the key must be single-Region.

Trap Granting KMS actions only in the reader's identity policy — a cross-account customer-managed key also needs them in the key policy in the source account.

2 questions test this
Shield Advanced proactive engagement requires Route 53 health checks on protected resources

Shield Advanced proactive engagement (and faster health-based detection) requires Amazon Route 53 health checks associated with each protected resource so the Shield Response Team can correlate a detected event with real application impact, plus configured emergency contacts and Business or Enterprise Support. Without the health checks the SRT will not reach out even when proactive engagement is enabled.

Trap Enabling proactive engagement and adding emergency contacts but skipping the Route 53 health-check association the SRT depends on.

7 questions test this
CloudFront geo restriction blocks at the edge before WAF; per-path geo rules need WAF

CloudFront's built-in geographic restriction (allowlist/blocklist) is the most efficient way to block whole countries because it rejects requests at the edge before they reach AWS WAF, so blocked requests never appear in WAF logs or counts. When you need geo decisions combined with conditions (e.g. restrict only /trading to the US), use a WAF web ACL that ANDs a geo-match statement with a URI-path match instead.

Trap Expecting requests blocked by CloudFront geo restriction to still be logged or counted by WAF — they are dropped before WAF runs.

5 questions test this
AWS Marketplace WAF rule groups are per-account and billed until removed from every web ACL

An AWS Marketplace managed WAF rule-group subscription is scoped to the single account that subscribed, so each account (e.g. production vs sandbox) must subscribe separately before the rule group is selectable. To stop the charges you must remove the rule group from every web ACL and Firewall Manager policy that references it in addition to unsubscribing; pin a managed rule group to a static version so vendor updates require review before taking effect.

Trap Assuming an org-wide or another account's Marketplace subscription carries over, or that unsubscribing alone stops billing while a web ACL still references it.

3 questions test this
Firewall Manager centrally deploys WAF, Shield Advanced, and DNS Firewall policies across the org

AWS Firewall Manager is the least-overhead way to enforce a single security policy across all accounts and new resources in an AWS Organization: it can push WAF web ACLs (including AWS and Marketplace managed rule groups), Shield Advanced protections with automatic application-layer mitigation, and Route 53 Resolver DNS Firewall rule groups, auto-remediating onto in-scope and newly created resources.

Trap Scripting per-account web ACLs or rule-group associations for org-wide coverage when a Firewall Manager policy applies and auto-remediates everywhere.

4 questions test this

Also tested in

References

  1. What is Amazon CloudFront?
  2. How AWS Shield works (DDoS overview)
  3. What is AWS WAF?
  4. OWASP Top 10 Whitepaper
  5. AWS Managed Rules rule groups list
  6. Rate-based rule statement
  7. Using labels on web requests in AWS WAF
  8. AWS Shield Advanced summary
  9. AWS Shield pricing
  10. Restricting access to an Amazon S3 origin (origin access control)
  11. Understanding response headers policies
  12. Using cross-origin resource sharing (CORS) with Amazon S3
  13. What is Amazon Security Lake?
  14. Open Cybersecurity Schema Framework (OCSF) schema Whitepaper
  15. Managed rule groups in AWS WAF (including AWS Marketplace)