Oh man, that ELB example hits home. I've spent so many billable hours with clients staring at that exact kind of query. Your point about the mental translation is spot on, but I think the pain runs deeper.
The issue isn't just that the `has any` syntax is alien. It's that Wiz's entire data model is a hidden graph you have to intuit, and the query language forces you to describe that graph traversal procedurally in a single line. When you're looking at the visualizer, you see nodes and edges. But writing WQL is like trying to give someone turn-by-turn directions through a city you've only ever seen on a map.
I've got a team right now that built a whole suite of compliance queries, only to have them silently break after a Wiz update because a field name changed from `publicIpAddresses` to `publicIPs`. No warning, no deprecation path. That's the real cost of a steep curve, it's not just the initial learning, it's the ongoing maintenance tax on your automation.
Have you tried building a cheat sheet of common patterns? We ended up having to create an internal "WQL for SQL people" guide, mapping common operations. It's the only way we could scale knowledge across the team without everyone getting stuck in that tab-switching loop.
Implementation is 80% process, 20% tool.
That ELB query example is the perfect illustration of the day one pain point. It took me ages to realize that `has any` isn't just a filter, it's the primary tool for *descending* into the graph to check relationships. You're not filtering a list of security groups on the ELB, you're asking "does this ELB have a relationship to any security group that meets these conditions?" The mental shift is huge.
What finally clicked for me was treating the pipe inside the lambda like a tiny, isolated query on the related node itself. It's like writing a sub-query for each hop. But you're right, the docs treat this as obvious syntax, not a fundamental concept shift.
Have you found a better way to learn the available fields inside those lambdas than just brute-force trial and error? I've started collecting my own cheat sheet from the UI's graph explorer, but it's a tedious workaround.
customer first
Your comment about the UI as a training tool is interesting. I've done exactly that, but it's a double-edged sword.
The generated WQL often introduces unnecessary aliases and verbose syntax that doesn't reflect the cleanest way to write it manually. It teaches you the grammar but not the poetry. More critically, it doesn't help you anticipate the next logical hop in a complex traversal.
For example, starting a query in the UI to find a pod with a vulnerability linked to a public service might generate the path, but you still have to intuit which fields on the vulnerability node are filterable and what the relationship name to the service actually is. The UI shows you the path visually, but the query language requires you to name that edge. That translation gap is where the friction remains.
Measure twice, spend once