How do I exclude dev/test environments from alert fatigue without breaking policy?

A recurring challenge in cloud security posture management platforms like Prisma Cloud is managing alert volume across heterogeneous environments, particularly when development and testing workloads generate policy violations that are intentional or low-risk. The core dilemma is maintaining comprehensive security coverage for production assets while preventing operational teams from being desensitized by irrelevant alerts from non-production systems.

I am currently architecting a governance model that requires distinct policy sets per environment tier, but Prisma Cloud's native hierarchy of accounts, resource groups, and tags presents several configuration complexities. My objective is to systematically exclude dev/test resources from specific alert policies without creating blind spots or duplicating policy frameworks.

The primary avenues I have identified within Prisma Cloud are:

* **Policy Scope using Tags:** Defining policy rules with exclusion conditions based on resource tags (e.g., `env:prod`). The efficacy of this method is entirely dependent on consistent and mandatory tagging governance, which is often incomplete in dynamic environments.
* **Account Group Segmentation:** Leveraging cloud account groups to apply policies only to specific sets of accounts classified as production. This is administratively cleaner but can be brittle if accounts host mixed workloads or if new accounts are onboarded without proper group assignment.
* **Alert Rule Filters:** Configuring filters within the alert rules themselves to suppress notifications for resources matching certain criteria, while still recording the finding in the console. This seems the most promising for reducing fatigue, but I am uncertain about the long-term audit implications.

My specific questions for the community are:

* What is the most maintainable and fault-tolerant pattern for environment-based policy segmentation? Have you found a hybrid approach combining tags and account groups to be most robust?
* How do you handle policies that *should* apply universally, like critical vulnerabilities (CVSS > 9), even in development? Do you create separate, severity-tuned policy duplicates for each environment, or use a single policy with environment-specific response actions?
* Are there programmatic best practices using Prisma Cloud's APIs or Terraform provider to ensure policy sets remain synchronized across environment definitions, thereby avoiding configuration drift?

I am particularly interested in implementations that have been validated at scale, where the tagging schema or cloud account structure may have evolved over time. The trade-off between administrative overhead and alert precision is the critical axis I am analyzing.