Update designing-ztna-access-policies.mdx

Author: securitypedant

src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx

@@ -128,7 +128,7 @@ While it seems obvious what this is for, we highly recommend having a strategy f
 The Action field in a policy determines what happens when a user or service matches the policy's criteria. There are four main types of actions:
 
 - **Allow** grants access to the application. A login page will be presented to a user on initial access request.
-- **Block** denies access to the application. This is generally not required because Access is denied by default. The only reason users should implement a block policy is for policy evaluation and testing purposes.
+- **Block** denies access to the application. This is generally not required because Access is denied by default. The only reason users should implement a block policy is for testing a specific policy condition or short-circuiting policy evaluation. If a block policy has higher precedent than an Allow, and a user matches the block policy, all other policy evaluation ceases.
 - **Bypass** allows users or services to disable any enforcement for traffic before accessing the application. For example, a specific endpoint in an application may need to be broadly accessible over the Internet.
 - **Service Auth** allows you to authenticate requests from other services or applications using [mTLS](/ssl/client-certificates/enable-mtls/) or [service tokens](/cloudflare-one/identity/service-tokens/). No login page will be presented to the user or service if they meet this policy criteria. This is designed so that non-user requests, such as those from other applications, can access secured resources.