Solid advice already in the thread, especially checking that custom policy queue health metric.
Since you asked for beginner-friendly steps, here's my quick checklist after an update:
1. Go to **Monitoring > Status** and look for "Custom Policy Scan". If it's not green, that's likely the core issue.
2. If green, pull up one of your broken policies and look at its **Last Evaluated** timestamp and resource count. If it's evaluating zero resources, the resource identifier changed.
3. Run this in the PCQL console to see the *current* resource type names:
```sql
SELECT DISTINCT resourceType
FROM aws.s3.bucket
LIMIT 5
```
Compare the exact string to what's in your policy's `resource` field. Even a capitalization difference can break it.
The 4.0.x updates did tweak some AWS resource naming. I had to change a few from `AWS::S3::Bucket` to `aws.s3.bucket`. 😅
Did the status page show green for the custom scan queue?
Yeah, that's the quickest root cause. The `cloud.service` filter is brittle, though. It's just another alias. Use `provider` and `type` from the raw inventory table instead.
They change those less often. Not never, but less.
If your query's dead after an update, rewriting it against the raw table gives you a few more version cycles before it breaks again.
Just my two cents.
That's a smart defensive strategy. The raw `provider` and `type` fields are indeed more stable because they map to the foundational inventory model, not a curated presentation layer.
However, this approach introduces a new dependency: you now have to join on the asset metadata tables yourself to get attributes like region or tags that `cloud.service` queries often bundle implicitly. You're trading one type of version fragility for the complexity of maintaining those joins, which can also shift subtly between releases if the underlying table relationships change.
For long-term policies, we've started storing these core resource mappings in a small configuration table that we can update centrally post-upgrade, rather than hard-coding identifiers directly into each policy's logic.
Great checklist from user370, but skip step 3 as written. That `DISTINCT` query can lie to you after an update because the console uses cached metadata.
Run this instead to get the raw inventory view the engine actually sees:
```sql
SELECT DISTINCT provider, type, raw->>'cloudType' as cloudType
FROM inventory
WHERE provider = 'aws' AND type LIKE '%s3%'
LIMITๅฎๆ 10;
```
Match *those* values against your policy. If they differ from your policy's `resource` field, that's your break. Updates love to silently rename the presentation layer while the underlying `provider`/`type` stays put. It's a nasty little versioning trick.
The "Last Evaluated" timestamp showing zero resources is the dead giveaway.
- elle