RabbitMQ Operator Policy Design Prompt
Design RabbitMQ policies and operator policies that enforce queue limits, TTLs, and queue types fleet-wide without colliding on priority or fighting application-declared arguments.
- Target user
- Platform engineers governing RabbitMQ at scale
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who governs a shared RabbitMQ cluster with policies and operator policies. Help me design a policy set that enforces guardrails without breaking teams. I will provide: - The guardrails I want: max queue length, message TTL, max length bytes, queue type enforcement, expires [DESCRIBE] - The blast radius: which vhosts/queues this should apply to and the name-pattern I'd match [DESCRIBE] - Existing policies already in place and any application-declared `x-` arguments teams set [DESCRIBE] - Cluster version and who declares queues (apps via client, or platform via definitions) [DESCRIBE] Your job: 1. **Policy vs operator policy** — explain the difference: a normal policy can be overridden by application-declared arguments and other policies by priority, while an operator policy sets hard ceilings that applications cannot exceed (the broker takes the more conservative of the two). Pick the right one per guardrail. 2. **Priority and conflict resolution** — only one policy applies per queue (highest priority wins, not merged). Design priorities so my guardrail policy doesn't silently shadow a team's needed policy, and explain why merging is NOT how policies combine. 3. **Pattern scoping** — write the `pattern` regex and `apply-to` (queues/exchanges/all) so it hits exactly the intended objects. Flag overly broad patterns that would catch system queues. 4. **Interaction with declared arguments** — show how an operator policy's `max-length` interacts with an app that declares its own `x-max-length`, and confirm the conservative-wins behavior so teams aren't surprised. 5. **Validate** — how to confirm with `rabbitmqctl list_policies` / `list_operator_policies` and per-queue `effective_policy_definition`, and a rollout that starts narrow. Output as: (a) the policy/operator-policy split per guardrail with reasoning, (b) the concrete `rabbitmqctl set_policy` / `set_operator_policy` commands with priorities, (c) the pattern scoping, (d) the verification commands. Apply new policies to a narrow test pattern on staging first, then widen. Because only the highest-priority policy applies (policies do not merge), a new policy can silently disable an existing one — verify each affected queue's effective policy before and after.
Why this prompt works
Policies are how you govern a shared RabbitMQ cluster, and the two facts that trip everyone up are baked into this prompt’s core. First: policies do not merge — exactly one applies per queue, the highest-priority one, and the rest are simply ignored. Engineers who assume policies stack will introduce a guardrail policy that silently disables a team’s existing one. The prompt makes priority design and per-queue effective-policy verification mandatory precisely to catch that.
Second: the policy-versus-operator-policy distinction is a governance lever, not a naming quirk. A normal policy yields to application-declared x- arguments and other policies; an operator policy sets a hard ceiling apps cannot exceed, with the broker taking the more conservative value. Choosing the wrong one means either teams route around your limit (normal policy where you needed a ceiling) or you clamp something teams legitimately need (operator policy where a default would do). The prompt forces that choice per guardrail with reasoning.
The pattern-scoping and interaction sections handle the practical edges: a too-broad regex catching system queues, and the surprise when an operator max-length clips an app’s own x-max-length. By demanding narrow staging rollout, before/after effective-policy checks, and explicit conservative-wins explanation, the prompt turns cluster governance into something verifiable instead of a source of silent message loss.