# Keep a Prometheus rule group's cluster scope aligned with its scraped label

> What must change in a managed Prometheus rule group when collection uses a custom cluster alias?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-165-keep-a-prometheus-rule-group-s-cluster-scope-aligned-with-its-scraped-label/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:11+00:00
- Modified: 2026-09-10T00:55:35+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

What must change in a managed Prometheus rule group when collection uses a custom cluster alias?

## Potentially affected

Azure Monitor managed Prometheus rule groups scoped to Kubernetes clusters.

## DSE recommendation

Review the cluster resource scope and scraped cluster label together before enabling the rule group.

## Article

## Source facts

Managed Prometheus rules inherit their evaluation scope from a rule group; individual rules cannot be attached directly to a Kubernetes cluster. A cluster-limited group’s scopes must still include its Azure Monitor workspace. The clusterName value must match the cluster label on scraped metrics. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-rule-groups).

If collection changes that label through cluster_alias, the group needs the updated clusterName. The property is optional with the default label. Without either a cluster-ID scope or clusterName, the group’s rules query every cluster in the workspace. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-rule-groups).

## Applicability

Use this check for Azure Monitor managed Prometheus rule groups scoped to Kubernetes clusters. Identify the workspace, intended cluster and collection configuration as separate review inputs. Do not infer the label solely from a cluster’s display name.

## DSE recommendation

DSE recommends pairing each rule group’s intended scope with a sample of the actual scraped cluster label. Include an alias change in the rule-owner’s change review, even when the cluster resource itself stays the same. Require an explicit decision before changing a group from cluster-specific to workspace-wide evaluation. Keep recording and alerting rules under the same scope review.

## Verification

Inspect the deployed scopes and clusterName, then run the relevant expression against known metrics from the intended cluster. Compare a second cluster to check the exclusion boundary. Preserve the query, observed labels and resulting rule behavior. Investigate missing results or unexpected cross-cluster results before treating the group as correctly targeted.

## Official references

[Microsoft Learn: Managed Prometheus rule groups](https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-rule-groups).

## Primary reference

- Name: Rule Groups in Azure Monitor Managed Service for Prometheus - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-rule-groups
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep a Prometheus rule group's cluster scope aligned with its scraped label,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-165-keep-a-prometheus-rule-group-s-cluster-scope-aligned-with-its-scraped-label/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.