# F5XC service-policy explainer

> Paste an F5 Distributed Cloud service_policy and see exactly how it matches: the server scope, the rule order, and every rule's action and conditions. iRules for XC, decoded.

- Tool: https://ronutz.com/en/tools/f5xc-service-policy-explainer
- Family: Security & WAF

---

## What it does

Paste an F5XC - F5 Distributed Cloud `service_policy` as JSON and the tool spells out exactly how it matches: the server scope it applies to, the order its rules are evaluated in, and for each rule its action and the conditions that must hold. It reads the policy definition entirely in your browser and evaluates nothing against live traffic.

## What a service policy is

On the F5 Distributed Cloud platform, a service policy decides which requests reach a load balancer and which are turned away, the platform's equivalent of the request-matching logic you would write as an iRule on a classic BIG-IP. A policy has a **server scope** that says which servers it governs, a **disposition** that sets the default behaviour, and an ordered **rule list**. Order matters: the rules are evaluated in sequence, and the first one that matches decides the outcome, so reading them top to bottom is how you understand what the policy actually does.

## How a rule matches

Each rule pairs an **action**, such as allow or deny, with a set of conditions that must all hold for the rule to apply. The tool renders each condition the way the schema defines it:

- the **matcher** and what it inspects (a source, a header, a path, and so on);
- its **criteria**, whether it matches by exact value, by regular expression, or by prefix;
- the **and/or logic** combining multiple values;
- any **inversion**, where the match is negated; and
- the **case sensitivity** of the comparison.

Rendering these plainly is the value: a service policy in raw JSON is hard to read, and a single misread matcher or an inverted condition is exactly the kind of thing that allows or blocks the wrong traffic.

## Grounded in the schema

The field names and shapes the tool understands follow the official F5 Distributed Cloud OpenAPI schema for the service policy and its rules, so the decode reflects the real object rather than a guess. The tool is local and zero-egress: it parses and explains the JSON you paste, and it never contacts the platform or tests the policy against real requests. Malformed input is reported rather than throwing.

## Using it

Paste a `service_policy` JSON spec and read the server scope, the ordered rules, and each rule's action and conditions. The decode is deterministic and local.

## Standards and references

- [F5 Distributed Cloud - API for ves.io.schema.service_policy](https://docs.cloud.f5.com/docs-v2/api/service-policy)
- [F5 Distributed Cloud - API for ves.io.schema.service_policy_rule](https://docs.cloud.f5.com/docs-v2/api/service-policy-rule)
- [F5 Distributed Cloud - Create Service Policy](https://docs.cloud.f5.com/docs-v2/multi-cloud-app-connect/how-to/app-security/service-policy)

## Related reading

- [Actions and Default Deny in XC Service Policies](https://ronutz.com/en/learn/xc-service-policy-actions-and-default-deny.md): A rule's action is ALLOW, DENY, or NEXT_POLICY. Beyond the verdict, a rule can attach modifiers like WAF, bot defense, or rate limiting that fire on a match. And the whole system is deny-by-default: a request that matches nothing is denied. Knowing these makes a policy's real effect legible.
- [Case Sensitivity and Transformers in XC Matchers](https://ronutz.com/en/learn/xc-matcher-case-sensitivity-and-transformers.md): In an XC service policy, header names are case-insensitive but header values, query keys, and cookie names are case-sensitive. Exact matches compare byte for byte unless you apply a transformer like LOWER_CASE first. This is the single most common reason a rule that looks right fails to match.
- [How F5 XC Service Policies Match a Request](https://ronutz.com/en/learn/how-xc-service-policies-match.md): An F5 Distributed Cloud service_policy has two moving parts: a set of predicates that scope which requests the policy even applies to, and a list of rules that decide what happens. A request matches only when every policy-level predicate is true and it matches one of the rules. This is the model everything else builds on.
- [Predicates and Boolean Logic in XC Service Policy Rules](https://ronutz.com/en/learn/xc-service-policy-predicates-and-logic.md): Inside one rule, every predicate you set is combined with AND, and an unset predicate is implicitly true. Inside one matcher, multiple values are combined with OR. Getting these two levels straight is the difference between a rule that matches what you meant and one that quietly matches too much or too little.
- [XC Rule Combining Algorithms: FIRST_MATCH, ALLOW_OVERRIDES, DENY_OVERRIDES](https://ronutz.com/en/learn/xc-rule-combining-algorithms.md): When a service policy holds a list of rules, the rule combining algorithm decides the order they are evaluated in. FIRST_MATCH walks top to bottom and stops at the first hit. ALLOW_OVERRIDES and DENY_OVERRIDES reorder by action first. The choice changes which rule wins when several could match.
- [XC Service Policy vs BIG-IP iRules: A Mental Model](https://ronutz.com/en/learn/xc-service-policy-vs-irules.md): iRules are event-driven scripts that run procedural code as a request is processed. An XC service policy is a declarative list of rules with predicates and actions. If you think in iRules, this maps the concepts across so you can read XC policies without hunting for the equivalent of a when-HTTP_REQUEST block.