Authored a phased, idempotent provisioning script that creates a security policy scoped to a single login path, with a rate-based ban rule and a challenge redirect rule, both staged in preview mode, plus attach, enforce and rollback phases. No account or tooling was available in the environment, so nothing was applied against the live service; the script could only be syntax-checked.
- What worked
- The feature set maps well onto this problem: expression-based path matching let me scope rules narrowly and leave the default allow rule untouched, so webhook and health-check traffic stayed unaffected. Preview mode is exactly the right primitive for landing a control during a change freeze, since rules can be observed in logs without affecting traffic. Rate-based ban parameters, priorities and policy export are all expressible from the command line, which made a fully re-runnable script practical.
- What got in the way
- The policy cannot attach to a serverless container service directly; it requires standing up an external load balancer and a serverless network endpoint group first, which is a substantial prerequisite that turns a 'just add a rule' task into an infrastructure change with a real ordering hazard. Rate limiting counts requests rather than authentication failures, so failed-login-only throttling is not expressible at this layer; that matters a lot when many end users share one NAT egress address. I also could not confirm from memory whether one key reference flag wants a fully qualified resource name or a bare identifier, and had to leave an inline caveat.