# Distinguish suppressed and limited dependency impact in a health-model preview

> How should an optional dependency differ from a degraded-but-important dependency in health rollup?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-314-distinguish-suppressed-and-limited-dependency-impact-in-a-health-model-preview/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:26:42+00:00
- Modified: 2026-09-10T01:40:02+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

How should an optional dependency differ from a degraded-but-important dependency in health rollup?

## Potentially affected

Azure Monitor health-model preview entities with child dependencies whose own signals are already configured.

## DSE recommendation

Choose impact behavior from the dependency's actual contribution to the user journey, not from a desire to keep the parent green.

## Article

## Source facts

In the Azure Monitor health-model preview, Suppressed impact prevents a child’s degraded or unhealthy state from influencing its parent. Limited impact instead reduces the propagated severity: a degraded child is treated as healthy, and an unhealthy child as degraded. Dependency aggregation determines how children combine, while the child’s impact setting changes its contribution. The tutorial assumes child entities already have signals determining their health. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/health-models/rollup).

## Applicability

Use these settings only within an approved preview evaluation. Distinguish a genuinely optional component from one whose failure leaves the service available with reduced capability. Establish the intended parent behavior before choosing either impact mode.

## DSE recommendation

Choose impact behavior from the dependency’s actual contribution to the user journey, not from a desire to keep the parent green. Ask the service owner to describe what users lose when that child degrades or fails. Use that explanation to justify suppression or reduced severity, and retain a separate operational responsibility for the child. Review the decision again if fallback behavior or the component’s purpose changes.

## Verification

In a controlled model exercise, inspect the child, parent and workload states as the child changes between the relevant health conditions. Compare the observed rollup with the documented service tolerance. Check that the child signal itself is meaningful before evaluating propagation. Preserve both the dependency setting and its business justification so a healthy parent is not later mistaken for proof that every component is healthy.

## Official references

[Microsoft Learn: Health-model rollup preview](https://learn.microsoft.com/en-us/azure/azure-monitor/health-models/rollup). Source reviewed September 9, 2026.

## Primary reference

- Name: Configure health rollup in an Azure Monitor health model (preview) - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/health-models/rollup
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish suppressed and limited dependency impact in a health-model preview,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-314-distinguish-suppressed-and-limited-dependency-impact-in-a-health-model-preview/
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.