A retailer froze the settings of a broad Block rule under change control, so its action and objects are locked even though rule order in the policy can still be edited. A partner API Allow rule added last release sits below that block rule, so partner requests keep landing in the block while the policy default remains Block all. Which change to the access control policy makes the partner flow match its intended rule?

The partner requests match the broad Block rule before evaluation reaches the partner API Allow rule. Moving the Allow rule above the Block rule fixes that precedence directly, while preserving the locked rule’s action and objects and retaining the policy’s Block all default. Changing the default to Allow could let partner traffic through, but it also changes the stated default-deny posture and may permit traffic not explicitly blocked; it therefore fails the requirement to keep the default Block all. Refining the Allow rule’s service or source match is a common way to correct an overly broad or inaccurate match, but here the partner requests already reach the broad Block first, so a more precise lower rule still cannot take effect. An upstream firewall allowlist can be useful for controlling traffic at a network boundary, but it does not change which access control policy rule handles these requests; the partner flow would still encounter the Block rule in this policy. Exam caveat: rule processing is platform-specific, so confirm whether the policy uses first-match, ordered evaluation and whether any implicit or higher-level rules take precedence. Practical check: after reordering, test a representative partner API request and verify that logs show the intended Allow rule as the matching rule, while unrelated traffic remains blocked by the unchanged default.