# Identify the related resource behind an Azure Policy compliance result

> For existence-check policies, Last evaluated resource can point to the related resource defined in the policy rather than the initially selected asset.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-430-identify-the-related-resource-behind-an-azure-policy-compliance-result/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:46+00:00
- Modified: 2026-09-10T02:04:57+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

For existence-check policies, Last evaluated resource can point to the related resource defined in the policy rather than the initially selected asset.

## Potentially affected

Azure Policy compliance investigations involving auditIfNotExists or deployIfNotExists definitions.

## DSE recommendation

Read the definition's related-resource requirements before proposing a change to the selected asset.

## Article

## Source facts

For auditIfNotExists and deployIfNotExists, compliance details include the definition’s details.type and optional existence-check properties. Last evaluated resource refers to a related resource from that details section.

Viewing current property values requires the read operation for the resource type; secret values are masked. Compliance details explain the present non-compliance reason, not when the responsible change occurred. Microsoft identifies change history as a separate preview experience. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/determine-non-compliance).

## Applicability

Identify the policy assignment, definition revision, selected resource and related resource named in the evaluation. Keep missing evidence caused by read access separate from the policy’s actual failure reason.

## DSE recommendation

DSE recommends tracing the existence condition to the precise related object before opening remediation work. Compare expected and observed properties and note whether the required object is missing or does not meet the condition. Avoid changing an unrelated VM or service merely because its name appears on the compliance page. Preserve masked values as masked rather than requesting secrets to complete the review.

## Verification

Use an approved representative evaluation to confirm the related-resource identity and reason. After the authorized correction, recheck the same assignment and condition and compare the resource state independently. Record the evaluation time separately from any established change time. If chronology is needed, collect the supported historical evidence without inventing it from the current compliance result.

## Official references

[Microsoft Learn: Determine causes of non-compliance](https://learn.microsoft.com/en-us/azure/governance/policy/how-to/determine-non-compliance). Source retrieved September 9, 2026.

## Primary reference

- Name: Determine causes of non-compliance - Azure Policy | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/determine-non-compliance
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Identify the related resource behind an Azure Policy compliance result,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-430-identify-the-related-resource-behind-an-azure-policy-compliance-result/
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.