SCS-C02 Threat Detection and Incident Response 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.

• ✓

  Create a web ACL, then add a rate-based rule to it, then associate the web ACL with an AWS resource, then test the rate-based rule, then monitor metrics and adjust thresholds.

  Why this is correct

  This sequence is correct because you must create the web ACL first to contain rules, then add the rate-based rule, then associate the ACL with a resource (e.g., ALB or CloudFront) to apply the rule, then test to verify behavior, and finally monitor to tune thresholds.

• ✗

  Add a rate-based rule to a web ACL first, then create the web ACL, then associate with a resource, then test, then monitor.

  Why it's wrong here

  This ordering is fundamentally invalid because AWS WAF has no construct for a standalone rule—a rate-based rule exists only as a rule statement within a WebACL. You must first create the WebACL to obtain the WebACL ID, then add the rule in an update or during creation; attempting to add a rule before the ACL exists has no target to attach to. The API model (e.g., UpdateWebACL) requires an existing WebACL, so the first step in any valid sequence must be creating the ACL.

• ✗

  Create a web ACL, then associate it with a resource, then add a rate-based rule, then test, then monitor.

  Why it's wrong here

  This sequence associates an empty web ACL with your resource, meaning that the rate-based rule is not yet in place when the ACL starts evaluating traffic. Although a WebACL can be updated while associated and the rule would take effect immediately after the update, this ordering creates an intentional or accidental window in which the resource is exposed to unthrottled traffic. For a rate-based rule to be active from the moment the resource is protected, the rule must be added to the ACL before association.

• ✗

  Create a web ACL, then add a rate-based rule, then test the rule, then associate the ACL with a resource, then monitor.

  Why it's wrong here

  Testing a rate-based rule requires the web ACL to be actively associated with a resource so that real or simulated traffic can be evaluated by the rule. If you test before association, the rule has no traffic path and thus cannot produce actual metrics or trigger a blocking action, so any 'test' is meaningless. The correct flow is to associate first, then send test traffic to the resource and observe the rule's behavior in AWS WAF metrics. This is also why the final monitoring step matters: you need the resource associated before you can derive useful thresholds from metrics.