Quickstart: Manual Effect in Azure Policy
Recently, a new feature called “Manual effect” popped out to users and it is still in the PREVIEW stage. It allows users to self-attest the compliance of resources or scopes. In another word, it gives users a chance to determine the compliance result of the specific resource and the reason. Currently, it is mostly used inside the Security related built-in policies and initiatives. In this post, I will briefly introduce what it looks like and how it works.
There are multiple built-in policies under the Security category to check the subscription level compliance results with manual effect. For the built-in example, you may check “Issue public key certificates” (policy definition ID: /providers/Microsoft.Authorization/policyDefinitions/97d91b33-7050-237b-3e23-a77d57d84e13). This policy only scans the target subscriptions but does not make any additional evaluation. It gives the control to users to change the compliance results for each target subscription.
Following is a custom policy example to illustrate how to use the manual effect and what is the result.
- Policy definition with manual effect
To illustrate the whole steps clearly, I created a custom policy which is checking the cloud services with “Prod” tag value. I set this custom policy with manual effect whose defaultState value is “Unknown”.
You can also use “Compliant” or “Non-compliant” as the defaultState. All applicable resources will be set to the default state specified in the definition.
The following screenshot is the evaluation results after this policy was assigned to my subscription. You can see the cloud service with “Prod” tag is marked as “Unknown”, the defaultState mentioned with the manual effect.
- Setting the compliance status by creating an attestation with REST API
You need to create attestations for each resource to change the compliance results of a resource or scope targeted by a manual policy. Currently, the only supported way to operate the attestation is through REST API.
In this example, I changed this cloud service compliance from the “Unknown” status to “Compliant” with the following REST API:
Attestations - Create Or Update At Resource - REST API (Azure Policy) | Microsoft Learn
You need to fill in the target resource information and the required evaluation result in the request body. The completed parameter list and their explanation can be found in the above doc link.
Following is an example to change the resource status from “Unknown” to “Compliant” with REST API.
Below is the request body being used for the example above:
{
"properties": {
"policyAssignmentId": "/subscriptions/xx",
"complianceState": "Compliant",
"expiresOn": "2023-06-15T00:00:00Z",
"owner": "the owner principal ID",
"comments": "test one cses to Compliant from Unknown",
"evidence": [
{
"description": "test one CSESto Compliant from Unknown",
"sourceUri": "https://gist.github.com/contoso/9573e238762c60166c090ae16b814011"
}
],
"assessmentDate": "2022-12-26T06:25:00Z",
}
}
- Updated compliance result
After the new assessment is completed, you will see the target resource has been changed to the required compliant result.
Reference Doc: Understand how effects work - Azure Policy | Microsoft Learn
Published on:
Learn moreRelated posts
Building Event-Driven Go applications with Azure Cosmos DB and Azure Functions
The Go programming language is a great fit for building serverless applications. Go applications can be easily compiled to a single, staticall...
July Patches for Azure DevOps Server
Today we are releasing patches that impact the latest version of our self-hosted product, Azure DevOps Server. We strongly encourage and recom...
Azure SDK Release (June 2025)
Azure SDK releases every month. In this post, you'll find this month's highlights and release notes. The post Azure SDK Release (June 2025) ap...
Exploring azd extensions: Enhance your Azure developer experience
A deep dive into the introduction of the Azure Developer CLI (azd) extensions and the azd extension framework to build extensions. The post Ex...