Outcome
By the end of this lesson, you will be able to construct a multi-condition filter using the grouped account and grouped type dropdowns and interpret the cascade filter behaviour.
| Tier | Operator |
| JTBD | ”Find ‘all running GCP databases in EU regions’ without writing a query.” |
| Personas | Platform Engineer · FinOps Analyst |
| Prerequisites | L1, L2 |
| Time | 10 minutes |
| Bloom verb | Construct (Apply) and Interpret (Understand) |
1. Concept
The Resources page has only a handful of filters, and two of them do most of the work: Grouped Account and Grouped Type.
Between them they answer nearly any question you would otherwise need to write a query for.
Grouped Account dropdown
A company on more than one cloud has a lot of accounts. A plain list of them stops being usable somewhere around 20 or 30, so this one groups them by provider and lets you tick as many as you like:
[Cloud Accounts ▾] 1 selected─────────────────────────────────────────────────────[ ] AWS 12 accounts [✓] prod-aws-us 941614... [ ] prod-aws-eu 182947... [ ] staging-aws-us 294018... [ ] dev-aws-shared......[ ] GCP 8 projects [ ] my-gcp-prod [ ] my-gcp-staging...[ ] Azure 5 subscriptions [ ] prod-azure-eu...Three behaviors matter:
1. Tick as many as you want. Any accounts, on any providers, in any combination. You get everything in all of them.
2. Tick the provider to take all of it. Ticking “AWS” selects every AWS account. Behind the scenes that sends one instruction rather than a list of twelve account numbers, which is quicker.
3. Mixed picks are sent as a list. Five accounts spread across two providers become a list of five identifiers, and the results come back filtered to exactly those.
Any of this stays usable at fifty accounts, which is where a flat list would have given up.
Grouped Type dropdown
The 380+ resource types fall into 9 categories. The Grouped Type dropdown organizes the type filter around these categories:
[Resource Types ▾] 3 selected─────────────────────────────────────────────────────[ ] Compute 23 types [✓] EC2 AWS [✓] Compute Engine GCP [ ] Azure VMs Azure [ ] ASG AWS...[ ] Kubernetes 12 types [ ] EKS AWS [ ] GKE GCP [ ] AKS Azure [ ] Deployment (all clouds) [ ] StatefulSet (all clouds) [ ] CronJob (all clouds)...[ ] Database 18 types [✓] RDS AWS [ ] Cloud SQL GCP [ ] Azure SQL Azure...[ ] Storage 14 types[ ] Networking 28 types[ ] Serverless 7 types[ ] Data & Analytics 16 types[ ] ML & AI 11 types[ ] Messaging 9 typesCategory-level checkbox ticks every type in the category. Counts show how many types are in each category. These per-category counts reflect the common, schedulable types surfaced in the dropdown; they are representative, not the full 380+ discovered set, so they do not sum to 380+.
Same component is reused on the Recommendations page for filtering rules by resource type: so muscle memory transfers.
Cascade filter behavior
Filters cascade. Selecting accounts narrows the available type / status / region values:
SCENARIO: A user selects two AWS accounts. The Type dropdown now showsonly types present in those two accounts. The Status dropdown showsonly statuses observed. The Region dropdown shows only regions wherethose accounts have resources.The cascade prevents the “I filtered by type X but got zero results” confusion. If a type isn’t present in the selected accounts, it doesn’t appear in the dropdown.
Exception: the account dropdown itself is NOT cascaded. It always shows all accounts (so a user can re-broaden the selection without manually clearing other filters first). A separate, unfiltered API call sources the full account list for that dropdown.
Why this matters at scale
A 300-account, 50,000-resource estate is unmanageable with flat filters. Grouped dropdowns plus cascade behavior make the same UI work at 5 accounts or 500 accounts without redesign.
Other filters
Beyond the two grouped dropdowns, the Resources page exposes:
- Status: Running / Stopped / Transitioning
- Region: multi-select, cascaded
- Schedulable: boolean (resources that can have schedules attached)
- Search: name or UID substring
- Schedule: filter to resources attached to a specific schedule
- Group: filter to resources in a specific group
- Tags: filter by tag key/value
Most queries combine 2-3 of these. Power users can stack many at once.
2. Demo
The signature query: “all running GCP databases in EU regions”
FILTER STATE RESULTS─────────────────────────────────────────────────────────(no filters) 12,400 resources+ Cloud Account = GCP (any) 3,200 resources+ Type Category = Database 47 resources+ Region = europe-west1, europe- west3, europe-west4 12 resources+ Status = Running 11 resources
Final: 11 running GCP databases in EU regions.Four clicks to construct.A second example: “EC2 + Compute Engine instances larger than t3.xlarge across all clouds, in production accounts only”
+ Cloud Account = (filter to prod accounts)+ Type = EC2, Compute Engine (mixed provider, in the Compute category)+ Tag: environment = prod+ Search: "xlarge" or "2xlarge" or "4xlarge"...Mixed-provider, tag-aware, instance-type-aware filtering: without writing a query.
3. Hands-on (6 min)
Run three filter exercises on your estate:
EXERCISE 1: All Kubernetes workloads (Deployments, StatefulSets, CronJobs) - Type Category = Kubernetes - Drill: list how many of each type
EXERCISE 2: Stopped resources older than 30 days - Status = Stopped - (sort by last-active date if available) - These are auto-remediation candidates
EXERCISE 3: Untagged resources across all clouds - Tag filter: environment = (no value) - Multi-cloud, all providers - These are tagging coverage gapsEach exercise is 2 minutes. The point is to internalize that the filter UI handles most cost-discovery questions.
4. Knowledge check
Q1
A user selects two AWS accounts. The Type dropdown now shows only 47 types instead of the full 191. This is:
A. A bug
B. A limitation
C. Intentional: cascade filtering
D. A different version of ZopNight
Show answer
Correct: C. Type values are narrowed to types present in the selected accounts. This prevents “I filtered by X and got zero” confusion. Cascade is by design. Type values are scoped to what is actually present in the current account selection.
Q2
A user wants “all running Kubernetes workloads across all clouds.” The most efficient filter construction is:
A. Type Category = Kubernetes (one click checks all K8s-category types across providers)
B. Filter each cloud separately, and then combine the results by hand after too
C. Use the search bar
D. Write a query in HogQL
Show answer
Correct: A. Then Status = Running. Two filters total. Category-level selection in the grouped Type dropdown is the right tool. One click handles cross-provider K8s types.
Q3
The Account dropdown does NOT cascade-narrow when other filters are applied. Why:
A. A bug
B. Backward compatibility with the older filter behaviour in the older product
C. So the user can re-broaden the account selection without first clearing other filters
D. Performance
Show answer
Correct: C. The account list always shows all available accounts, sourced from a separate unfiltered API call. Deliberate UX. The account dropdown is the broadest filter; allowing the user to re-broaden without first clearing downstream filters is a usability choice.
5. Apply
The Resources page exposes the filter UI:
- Resources page filters: open and experiment
- Grouped Type dropdown is reused on the Recommendations page: the same component
- Saved filter URLs can be bookmarked: every filter combination is reflected in the URL parameters
For complex programmatic queries (across many dimensions, scriptable), use the MCP read-only tools (see T6: AI-Powered Cloud Ops). The filter UI is for interactive exploration; MCP is for repeatable queries.
Related lessons
Glossary terms touched
Grouped Account dropdown · Grouped Type dropdown · Cascade filter · 9 type categories