Am I the only one who finds the policy creation wizard overly complex?

You're not being impatient. You're describing the standard sales-to-reality gap. That wizard isn't for you, it's for the checklist during the procurement call. "Granular control" and "guided configuration" are just marketing terms for "we couldn't design a coherent single-page form."

The real cost isn't the hour you lost. It's the annual license fee you pay for a feature so cumbersome your team will avoid using it, which then gets cited as "low adoption" justifying the next feature-packed module.

Spot on about the procurement checklist. It creates a vicious cycle: they build for the demo, we avoid the feature, then they use our own "low adoption" metrics to justify building more complex stuff nobody asked for. Seen it happen with approval workflows in three different CRMs.

The real irony? That "granular control" often makes the system less secure because admins just approve blanket policies to avoid the wizard.

I understand the frustration, but that sequential scoping and logic separation is intentional. It's a pattern for building complex policies that apply to multiple resource types or environments. A container policy, a host policy, and a cloud function policy all need different scopes but could use the same "running as root" rule logic.

The complexity you're hitting for a simple container check is real, though. The interface serves the broadest use case, which makes the simple ones feel overbuilt. A quicker "quick policy" template for common checks like this would help a lot. For now, you can often clone an existing policy from the library and just modify the scope, which skips most of the wizard.

"It's intentional, sure. But intention doesn't justify bad UX. If your 'broadest use case' makes the common case painful, you've failed at abstraction.

And cloning from a library is just a workaround for bad design. That's an ops tax. Time spent navigating their poor interface isn't free - I calculate it in team-hours against the license cost.

The wizard should serve the 80%, not the 20%."

Exactly. That "ops tax" calculation is the most important metric most teams ignore during procurement. You're quantifying what I call the configuration burden, which directly impacts total cost of ownership.

When we evaluate vendors, I always ask for the average time to configure their five most common policies from scratch. If they can't provide that data or it seems high, it's a red flag. A wizard that serves the 20% often means the vendor prioritized feature checkboxes over actual user velocity.

The real failure is when there's no escape hatch from the wizard for common tasks. A good system offers both the granular flow for edge cases and a simple form for the 80% scenario. Forcing everyone through the complex path is just lazy design.

You're right about the clicks. The worst part is the "preview" at the end that shows a JSON blob nobody can parse. I just bypass the wizard entirely now.

For your root container check, skip it. Define the policy as code and apply it via CLI or pipeline. It's faster.

The wizard is for people who don't know the underlying model. Once you do, it's just in the way.

Completely agree on bypassing the wizard for speed, but that JSON preview is actually more useful than it seems. It's the system's internal model, and learning to read it is the key to escaping the GUI entirely.

The issue is they show the fully rendered policy with all defaults expanded, which is indeed a mess. I always check the "diff" view against a known good baseline, or use `jq` to filter. Once you understand the structure, you can template policies as code for entire environments, which is where the real velocity is.

Your point about the wizard being for those who don't know the model is correct, but it creates a knowledge cliff. New team members either struggle with the wizard or must immediately learn the underlying schema. There's no gradual on-ramp.

You're definitely not being impatient. That feeling of building for the sales demo is spot on. I've clocked the same frustration - I sometimes wonder if they A/B test the wizard against "time to give up and open a support ticket."

The sequential flow kills me because you can't easily go back. You realize on step three that your scope in step one was wrong, but there's no live preview to catch it. You're basically writing a config blind.

There is a shortcut, though painful: for that root container check, I found a similar policy in their examples library, downloaded the JSON, and just swapped the image name. Still too many clicks, but at least it bypasses the worst of the "help" text.

The sequential flow with no preview is what gets me too. It forces you to think in their abstraction layers instead of the actual policy you want. I've started keeping the API docs open in another tab just so I can understand what the wizard fields will translate into.

You're right about the firewall comparison. I can configure an AWS security group rule in under 30 seconds because the form shows the whole context. That wizard feels like they designed the backend first, then just mirrored the data model into a UI without considering the mental model of someone trying to solve a problem.

For your specific case, if you're dealing with ECS or EKS, I'd skip the wizard and write it as a short OPA rule in a Config rule. It's fewer characters than clicking through those screens.