SCS-C02 Infrastructure Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  It blocks IPs that send more than 2000 requests and allows requests containing '<script>' in the body.

  Why this is correct

  The web ACL contains two rules evaluated in order. The first is a rate-based rule with a threshold of 2,000 requests per IP address over the evaluation window; when that limit is exceeded, the Block action immediately terminates the request. Requests that stay below the threshold continue to the second rule, an XSS match rule whose action is set to Allow, so any request with `<script>` in its body is explicitly permitted rather than blocked. The net effect is therefore IP-based volumetric blocking only, with no content-based blocking.

• ✗

  It allows all traffic because the rules are misconfigured.

  Why it's wrong here

  Although the XSS rule is configured with an Allow action, the rate-based rule is not misconfigured: it has a valid threshold of 2,000 requests per IP and a Block action, and it is evaluated before the XSS rule. Any single IP that sends more than 2,000 requests within the rate-based window is blocked, so not all traffic can pass. Traffic is only allowed for IPs that stay under the volume limit, and such traffic is then explicitly allowed even if it contains `<script>`. The claim of 'all traffic allowed' ignores the effect of the first rule.

• ✗

  It blocks both SQL injection and XSS attacks.

  Why it's wrong here

  This outcome would require separate SQL injection and XSS match rules, but the exhibit shows only a rate-based rule and an XSS match rule. The rate-based rule inspects request counts, not payload contents, so it cannot identify SQLi or XSS patterns such as `<script>` or `' OR 1=1 --`. Furthermore, the XSS rule's action is Allow, not Block, so it does not stop XSS requests; it permits them. Thus neither attack type is actually blocked by this configuration.

• ✗

  It blocks SQL injection attacks and allows XSS attacks.

  Why it's wrong here

  The first rule is a rate-based rule, not a SQL injection match rule; it counts requests per IP and triggers on volume, so it would never detect or block SQLi payloads. The second rule does allow XSS patterns because its action is Allow, but that does not mean SQLi is blocked anywhere else in the ACL. Because no rule inspects for SQLi and the XSS rule is permissive, the real behavior is that both SQLi and XSS content pass through as long as the request rate stays under 2,000, so the statement's SQLi-blocking half is false.