When a rule sits in count mode, every matching request is logged and not one of them is stopped, while the dashboard fills with matches that read like protection. That gap between recording a match and acting on it is what block vs count mode names, and a DDoS test exists to find out which side of it a given rule is on. It is a configuration property of nearly every WAF and rate rule, and the single most consequential one to get wrong.
What the two modes actually do
The two modes share a detection path and diverge only at the last step. A rule evaluates a request, decides whether it matches, and records the match either way. In count mode, sometimes called monitor mode, that is the end of it: the request continues to the origin with a log line trailing behind it. In block mode, sometimes called enforce, the same match ends in a drop at the edge.
The providers each have their own word for the passive setting. AWS WAF labels a rule action COUNT, Azure's WAF calls the equivalent posture Detection, and Google Cloud Armor calls it preview. The names differ but the behaviour is one thing: the rule sees everything and prevents nothing. Because both modes register a match, a console that reports rule hits looks identical whether the rule is enforcing or merely observing.
Why count mode is the most common false green
Count mode exists for a good reason. It is how a new rule is validated safely, watching what it would catch before it is allowed to drop anything, so a badly scoped rule does not start 403-ing real customers the moment it ships. The danger is not the mode, it is the rule that is left in it. A rule deployed to monitor during tuning and never promoted to enforce is operationally absent under attack, yet it appears active in every metric that counts hits.
That is the trap a test is built to catch: a rate-based rule or managed group that looks complete in the console, every rule present and matching, quietly passing attack traffic straight to the origin because none of them were ever switched to block. Nothing in the hit graph distinguishes that state from a fully enforcing one.
The staged rollout most teams follow makes the gap easy to leave open. A rule ships in count, sits there for a few days while someone reads its logs, and is meant to be promoted once it looks safe. The promotion is a separate manual step, and separate manual steps are the ones that get skipped when the person who deployed the rule moves on to the next thing. Multiply that across a managed rule set and a handful of custom rules, and a policy accumulates a quiet mix of enforcing and observing rules that no single dashboard view distinguishes.
What a DDoS test measures
A test refuses to trust the match count. It measures whether traffic that matched a rule actually reaches the origin, because that, not the log line, is the only evidence the rule is doing anything. Reaching the backend means count mode; being dropped means enforce. It also measures time-to-enforce, the interval between a rule matching and its action taking hold, which matters when rules are promoted automatically during an incident.
The measurement has a second axis that pulls the other way. Promoting a rule from count to block is exactly when a false positive starts costing real users, so a rule that is safe to observe is not automatically safe to enforce. Confirming a rule blocks what it should while sparing legitimate traffic, and doing it without shedding real users along the way, is worked through in DDoS testing without disrupting production.