Infrastructure Security practice questions

Shield Advanced cost protection credits scaling charges (for example data transfer, Auto Scaling, Route 53 queries) caused by a DDoS attack only on resources that are protected by Shield Advanced. The Shield Response Team (SRT) is available to subscribers with Business or Enterprise Support.

Both the distribution and the ALB incurred attack-driven charges, so both must be Shield Advanced protected resources for cost protection to cover them, and the Enterprise Support plan gives Shield Response Team access. Protecting the distribution does not cover its origin, and leaving the distribution on Shield Standard leaves its data transfer charges uncovered. The Anti-DDoS managed rule group on Shield Standard mitigates floods on both resources but provides neither cost protection nor SRT access.

1. Map the requirements: credits for attack-driven charges and expert help mean Shield Advanced.
2. List every resource whose charges spiked: the distribution and the ALB.
3. Recall that cost protection applies only to protected resources, so add each of them.
4. Confirm the support plan is Business or Enterprise so the SRT can be engaged.

Exam tip: Shield Advanced cost protection follows the protected-resource list: every resource whose charges you want credited must be added as a protection.

A rate-based rule counts requests per aggregation key over a time window and acts on keys above the threshold; a scope-down statement limits which requests are counted. At a CloudFront web ACL, the source IP is the viewer address.

Credential stuffing is a volume problem on valid requests, so a rate-based rule with Block, keyed on the viewer address and scoped down to POST /login, stops the abusive clients while other pages are never counted. Dropping the scope-down counts all browsing toward the limit. A Count action only observes. Keying on X-Forwarded-For at the edge trusts a header the attacker controls; forwarded-IP aggregation is for a web ACL that sits behind a proxy you trust, such as an ALB behind CloudFront.

1. Recognise a volume attack on well-formed requests, which content rules cannot catch.
2. Use a rate-based rule with a Block action so offending clients are stopped.
3. Scope it down to POST requests for /login so normal browsing is not counted.
4. Key on source IP because the web ACL is on CloudFront, where that is the viewer address.

Exam tip: Rate-limit a sensitive path with a scope-down statement, and key on source IP at the edge; forwarded-IP keys are for web ACLs behind a trusted proxy.

New WAF rules and managed rule groups are introduced count-first: rule action overrides set to Count record matches without terminating evaluation, and the team promotes them to Block after reviewing metrics, sampled requests and logs.

Overriding the group's rule actions to Count lets the rules evaluate production traffic and record what they would have blocked, with no customer impact. Placing the group later in priority order still blocks matching requests. CAPTCHA is an interrupting action and breaks non-browser clients such as a mobile app's API calls. A staging replay does not see real traffic.

1. Separate observing a rule from enforcing it: only Count is non-terminating.
2. Add the managed group with its rule actions overridden to Count.
3. Review WAF metrics, sampled requests and logs for matches against real traffic.
4. Add exceptions for legitimate patterns, then remove the overrides so the rules block.

Exam tip: Introduce new WAF rules in Count against real traffic; CAPTCHA and Challenge still interrupt users and break non-browser clients.

AWS WAF logs (to CloudWatch Logs, S3 or Data Firehose) record each request with the action taken and the terminating rule, plus non-terminating matches and labels. When a rule inside a rule group decides, terminatingRuleId holds the rule group and ruleGroupList[].terminatingRule.ruleId names the rule inside it.

Filtering the WAF logs for the campaign URL and action BLOCK identifies the exact rule. terminatingRuleId names the web ACL rule that decided; because this web ACL holds several managed groups, it will usually be a group, and the ruleGroupList entry's terminatingRule gives the specific rule inside it. Per-rule CloudWatch metrics are aggregated across all paths and cannot be tied to one URL. CloudFront logs show the 403 but not the rule. CloudTrail captures configuration API calls, not request evaluations.

1. Pick the data source that records per-request WAF decisions: the WAF logs.
2. Filter for the campaign URL and action BLOCK.
3. Read terminatingRuleId; if it is a rule group, read ruleGroupList's terminatingRule for the rule inside it.
4. Then fix narrowly: override that rule to Count or add a targeted exception.

Exam tip: The WAF logs name the rule that blocked a request: terminatingRuleId for the web ACL rule or group, ruleGroupList for the rule inside a group.

Managed rule groups support rule action overrides on individual rules (typically to Count), so a false positive can be removed without excluding requests from the rest of the group. A scope-down statement or a terminating Allow excludes requests from every rule.

Overriding only SizeRestrictions_BODY to Count removes the false positive while upload requests are still inspected by every other rule in the group. A scope-down statement and a higher-priority Allow both stop the false positive but take uploads out of the cross-site scripting checks as well. Pinning an older version does not remove the size rule and stops the group from receiving updates. If size enforcement is still wanted elsewhere, a custom rule can re-apply it with a label match.

1. Identify the blocking rule from the WAF logs (terminatingRuleId).
2. Apply the constraint: uploads must still pass through the group's other rules.
3. Reject fixes that exclude the path from the whole group (scope-down, Allow).
4. Override just the offending rule's action to Count and verify the upload works.

Exam tip: Fix one noisy managed rule with a per-rule Count override; scope-downs and Allow rules remove the whole group's protection for that traffic.

Locking an internet-facing ALB to one CloudFront distribution takes two layers: the CloudFront origin-facing managed prefix list on the security group, and a secret custom origin header verified by an ALB listener rule. The prefix list alone admits any customer's distribution. CloudFront VPC origins (internal ALB in a private subnet) remove the public endpoint altogether.

The origin-facing prefix list is shared by every CloudFront customer, so an attacker's own distribution arrives from an allowed address. Adding a secret header at your distribution and forwarding only when an ALB listener rule matches it authenticates traffic as yours. The IPv6 and regional-edge-cache options misread how the prefix list and security groups work. Reusing the web ACL on the ALB is impossible across scopes, and a Regional web ACL would still not restrict who can reach the origin. Without the internet-facing constraint, a CloudFront VPC origin with an internal ALB is the simpler fix AWS recommends.

1. Note that the prefix list restricts sources to CloudFront, not to your distribution.
2. Configure the distribution to add a secret custom header with a value kept in Secrets Manager.
3. Make the ALB listener forward only when the header matches and return 403 by default.
4. Rotate the header value by updating the distribution and listener rule together, or move to a VPC origin when the ALB can become internal.

Exam tip: The origin-facing prefix list proves "from CloudFront", not "from my distribution"; add a verified secret header, or use a VPC origin with an internal ALB.