Azure Governance and Management Blog articles

A closer look at noise reduction in Stacks What-If

torreyt — Thu, 08 Oct 2026 16:12:33 GMT

Following the general availability of what-if for Azure Deployment Stacks, this article deep dives into the co-released feature of "noise reduction", which was a top community feature ask from Deployment Stacks customers. In this article, we will cover what noise reduction solves, how it works, and how to get started with noise reduction. For the full reference, see Noise reduction in deployment stack what-if results on Microsoft Learn.

The problem with Deployments What-if results

What-if for deployments compares a Bicep file or ARM template against the current state of the deployed resources and reports every difference between the two. Historically, a large share of those differences are changes that won't actually happen, and they're considered noise.

Noise is a difference that what-if reports but that deploying the template wouldn't actually change. It shows up when the property values declared in your template differ from the resource as it exists in Azure for reasons that have nothing to do with your edit. A resource provider fills in default values for properties you left out. It also returns read only properties that no template can declare, which surface as false deletions because nothing in your file matches them. Write only properties can add noise too, but only when what-if doesn't know that a property is write only, because the value you deploy is never returned to compare against.

This has been one of the most common pieces of feedback we receive about what-if. Noise makes a result harder to trust, and a result that is not trusted is slower to act on. Review turns into a manual exercise, because someone has to read every line and dismiss the ones that nobody authored. As a stack grows to manage more resources, the problem compounds.

What noise reduction looks like

Here is what a regular deployment what-if response looks like:

In this example, the property values of properties.sqlEndpoint and properties.minimalTlsVersion on the Cosmos DB account, sku.tier and properties.kafkaEnabled on the Event Hubs namespace, and the five properties.siteConfig values on the web app show up as changes but are actually noise (given they were not a part of the original template).

Now, with Deployment Stacks What-if, the response is more accurate and the noise is removed, as shown in the following example.

Where the noise comes from

Noise most commonly comes from default properties for resource types, but it can also come from read only properties, and from write only properties that what-if doesn't recognize as write only. Below are common examples of such noise:

Resource type	Property reported as changed	Why it appears
Cosmos DB account	`properties.sqlEndpoint`	Server generated, read only
Cosmos DB account	`properties.minimalTlsVersion`	Provider default applied after deployment
Event Hubs namespace	`sku.tier`	Derived from sku.name by the provider
Container app	`properties.runningStatus`	Runtime state rather than configuration
Role assignment	`properties.principalType`	Resolved by the provider at creation
Stream Analytics job	`properties.runtimeMode`	Provider default applied after deployment

The same pattern holds as the resource types vary. On a separate stack managing 13 resources spanning storage, networking, Event Hubs, Container Registry, App Service, Log Analytics, and Application Insights, what-if for deployments returned 30 property level differences on an unedited template.

Stacks What-if against the same stack returned none.

How Deployment Stacks filter noise

A Deployment Stack keeps a record that a standalone deployment does not. It captures the noise that was already present after the last successful deployment of that stack.

After each successful stack deployment or update, Azure runs what-if and saves the result as a baseline. That baseline captures the differences that come from Azure itself, such as provider defaults, rather than from any later edit you make to the template.

The next time you run Stacks What-if, Azure compares the new result against that baseline. If a property looks the same in both, Azure drops it from the output, because the edit you are previewing is not what introduced that difference.

Noise reduction is enabled in all regions and there is no flag to set. It depends on a baseline, so it applies to stacks that were deployed or updated on or after August 13, 2026. If a stack hasn't been deployed since then, deploy or update it once to record a baseline. The next Stacks What-if run uses that baseline. If a result looks noisier than you expect, check when the stack was last deployed, because a missing baseline is the most common cause.

What noise reduction does not hide

Filtering against a baseline removes differences that were already present when the baseline was recorded, not differences that appear afterwards. In a test stack, an Azure Policy assignment added a myTag tag to every managed resource at deployment time. What-if for deployments reported tags.myTag as a deletion on all four resources, because nothing in the template declared it. Stacks What-if reported those same four resources as NoChange, because the tag was already in the baseline. Adding a different tag directly to one of those resources after the stack had deployed produced the opposite outcome. That tag was not in the baseline, so Stacks What-if reported it. Drift introduced after a deployment still surfaces.

Getting started

The quickest way to evaluate this is against a stack you already have. Run Stacks What-if with the unchanged template and compare the result to what what-if for deployments reports for the same file. Unlike a deployment what-if, a Stacks What-If Result is itself an Azure resource, so the name you give it, noise-check in the examples below, becomes the resource name you use to retrieve that result later:

Azure PowerShell:

New-AzResourceGroupDeploymentStackWhatIfResult `
  -Name "noise-check" `
  -ResourceGroupName "my-rg" `
  -StackResourceId "<stack-resource-id>" `
  -TemplateFile "main.bicep" `
  -ActionOnUnmanage DetachAll `
  -DenySettingsMode None `
  -RetentionInterval "PT3H"

Azure CLI:

az stack-whatif group create \
  --name "noise-check" \
  --resource-group "my-rg" \
  --stack-id "<stack-resource-id>" \
  --template-file "main.bicep" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Keep in mind that --action-on-unmanage and --deny-settings-mode affect the Stacks What-if result, because they change how the stack would manage your resources. The clearest way to see this is to remove a resource from your template and run the same evaluation twice. With detachAll, that resource is reported as v Detach and its management status moves from managed to notManaged, but it stays in Azure. With deleteResources, the same resource is reported as - Delete and is listed again under Resources Marked for Deletion. The template change is identical in both runs, so the difference in the result comes entirely from actionOnUnmanage. Running Stacks What-if does not change any deployed resource. It does create one resource, the Stacks What-If Result itself, which is how the output is stored so you can retrieve it later. Stacks What-if is available at resource group, subscription, and management group scope, in Azure CLI, Azure PowerShell, and the Azure SDKs.

Azure PowerShell takes PascalCase enum values such as DetachAll and None, written without quotes. Azure CLI documents the camelCase spellings detachAll and none. Use the spelling each tool documents, and if a value is not recognized the error lists the allowed values.

The retention interval sets how long Azure keeps the result before cleaning it up. It currently accepts ISO 8601 durations between PT1H and PT3H, so the PT3H used in these examples is the longest window available today. If you intend to hand a result to a reviewer as an approval artifact, plan around that window, because the result is removed once it expires.

The result is printed in up to three sections. Changes to Stack covers the stack resource itself, such as deny settings, and appears when those change or when the stack does not exist yet. Changes to Managed Resources lists every managed resource with its change type and property level detail. Resources Marked for Deletion repeats, as an explicit list with a count, the resources the run predicts will be deleted, which is the section to read first when you are reviewing a risky update.

You need permission to read the deployment stack and the resources it manages, and permission to create the result. The operations involved are Microsoft.Resources/deploymentStacks/read, Microsoft.Resources/deploymentStacksWhatIfResults/write to create a result, Microsoft.Resources/deploymentStacksWhatIfResults/read to retrieve one, and Microsoft.Resources/deploymentStacksWhatIfResults/delete to remove one. Because the evaluation compares your template against live resource state, the identity running it also needs read access to the managed resources themselves.

Tell us what you think

If Stacks What-if reports a property you did not change, open an issue in Azure/deployment-stacks and include the resource type, the full property path as it appears in the output, and the correlation ID. Because the result is a stored resource rather than terminal output, the correlation ID is saved on it and can be read back at any time with az stack-whatif group show --name <result-name> --resource-group <resource-group> --query properties.correlationId, or from the CorrelationId property returned by Get-AzResourceGroupDeploymentStackWhatIfResult.

Resources

Noise reduction in deployment stack what-if results. The Microsoft Learn article on noise reduction, covering where noise comes from, how the baseline works, and what it doesn't filter.
Preview deployment stack changes with what-if. Change types, running Stacks What-if at each scope, retrieving and deleting Stacks What-If Resources, and noise reduction.
Create and deploy Azure deployment stacks in Bicep. The main Deployment Stacks article, including actionOnUnmanage.
Preview Bicep deployment changes by using what-if. What-if for deployments, included for comparison.
az stack-whatif command reference. The Azure CLI command group for Stacks What-if at resource group, subscription, and management group scope.
New-AzResourceGroupDeploymentStackWhatIfResult. The Azure PowerShell cmdlet reference, including the subscription and management group equivalents.
Deployment stacks what-if results REST API. The Microsoft.Resources/deploymentStacksWhatIfResults reference, which is the contract the SDKs are generated from.

Open Sourcing the Azure Policy Linter!

stevenbucher — Mon, 28 Sep 2026 15:02:05 GMT

Today we’re excited to share that the Azure Policy Linter is now open source on GitHub: github.com/Azure/azure-policy-linter. It’s a command-line linter for Azure Policy definitions that surfaces known issues, gotchas, and best practices that you can run when authoring your policy definition and before you assign a policy to your environment.

Why we built it

Writing a good policy is hard. It requires deep knowledge of the policy language, how each effect behaves, and the API surface of every resource type you’re targeting.

The linter codifies that expertise into a set of automated rules. Instead of learning every gotcha the hard way, you get actionable error, warning, and informational findings on your specific policy definition immediately.

The linter fits naturally into the way policy authors already work:

Shift governance mistakes left. Catch problems on your laptop or in CI, long before a bad policy reaches a subscription and blocks legitimate deployments or produces misleading compliance results.
Lint one file or a whole library. Point it at a single definition, or run it across up to 1,000 files in one parallelized pass with file-specific results.
Get machine-readable output. Emit findings to the console for humans, or to JSON (--output results.json) so you can gate pull requests and pipelines.
Tune it to your scenario. Rules are grouped into rule sets. The default rule set covers general-purpose checks; you can list available sets (--list-rule-sets), apply a specific one, or combine several (--rule-set <name> --rule-set default).
Understand every finding. Each rule ships with its own documentation page under docs/Rules/, explaining the why, plus violation and corrected examples.

Installing NuGet

The linter is now published on NuGet. Install the Microsoft.Azure.Policy.PolicyLinter.Cli CLI as a global .NET tool by running

dotnet tool install --global Microsoft.Azure.Policy.PolicyLinter.Cli

Then invoke it as

policylinter

To consume the linter as a library instead, reference the Microsoft.Azure.Policy.PolicyLinter.Core package.

Installing from source

You can also run directly from source. Clone the repo, build the solution, and invoke the CLI with dotnet run:

git clone https://github.com/Azure/azure-policy-linter.git cd azure-policy-linter dotnet build src/dirs.proj --configuration Release dotnet run --project src/PolicyLinter.Cli -- <path-to-policy-json>

Running the linter

Once installed, point policylinter at one or many definitions:

# Single file policylinter c:\path\to\policyDefinition.json # Multiple files (up to 1,000 in a single, parallelized run) policylinter policy1.json policy2.json --output results.json # See which rule sets are available, then pick one policylinter --list-rule-sets policylinter policy.json --rule-set <RuleSetName> --rule-set default

Run policylinter --help at any time for the full list of options.

One great use case is to ask GitHub Copilot to run the policy linter against the policy definition you are authoring, and it can read the output and help you fix your definition to meet all the rules suggestions!

Policy linter rules

The linter’s real value is in its rule catalog. Every rule has its own documentation page with the rationale plus violation and corrected examples. Here are few of the more common rules:

1. All parameter references must resolve (Error)

Every parameters('...') reference must point to a parameter actually declared in the policy. A single typo — referencing efect when you declared effect — means the policy fails to deploy or evaluate. This rule catches that class of showstopper bug instantly, before you ever push the definition to Azure.

2. Risky effect parameter default value (Warning)

Parameterizing the effect is a best practice — but if the effect parameter defaults to an enforcement effect like deny, modify, or deployIfNotExists, then any assignment that doesn’t explicitly override it will enforce by default. That’s rarely what the person assigning the policy expects. The rule flags risky defaults and steers you toward a safe default like audit (or no default at all).

3. Read-only field alias (Warning)

This is exactly the kind of hidden gotcha that’s almost impossible to learn from docs. If your policy keys off a field alias that maps to a read-only property, that property can’t be relied on during enforcement — callers aren’t required to send it, and providers often ignore it if they do. A deny policy built on a read-only alias may simply not work. The linter draws on the public Azure REST API specs to know which properties are read-only.

4. Broad type matching operator (Warning)

Comparing the type field with a broad operator like like, contains, or match can silently match resource types you never intended to govern. For example, "contains": "virtualMachines" matches both Microsoft.Compute/virtualMachines and .../virtualMachines/extensions. The rule pushes you toward equals (single type) or in (an explicit list) so your scope is exactly what you meant.

These are just a few highlights, the linter ships with many more, covering effect parameters, API-version mismatches, and readability simplifications. Browse the complete, per-rule documentation in docs/Rules/.

Don’t see a rule you need? Add your own

The rule catalog captures the gotchas we’ve hit, but you know your environment best. If there’s a check that would help your team and it isn’t there yet, the linter is designed to be extended. The repo’s Adding a linter rule section walks you through it, backed by two guides, what a good rule looks like and how rules are wired up in code. Plus there is a SKILL.md file you can have your GitHub Copilot agent use to help you author a rule!

Try it and tell us what you think

The Azure Policy Linter is open source under the MIT License. Clone it, build it, and run it against your own definitions:

Repo: github.com/Azure/azure-policy-linter
Rule catalog: docs/Rules/
How rules are designed: docs/linter-rule-design.md

We’re not accepting pull requests just yet, but we would love your feedback, bug reports, gotchas we haven’t codified, and rule ideas. Please open an issue and help us make Azure Policy authoring safer and simpler for everyone.

Public Preview Annoucement: Azure Policy Custom Policy Versioning!

stevenbucher — Tue, 15 Sep 2026 18:02:19 GMT

In 2024 we introduced versioning for built-in definitions and initiatives. Today we are extending that capability to your own policies! Custom policy versioning is now in public preview. Custom definitions and custom initiatives can store and reference multiple versions under a single definition ID, using the same model built-ins use.

What's new?

Every custom policy definition and initiative now has a top-level version property in {major}.{minor}.{patch} format. This gives you:

Predictable updates. - Pin an assignment to a version so an edit never silently changes what is enforced.
Safer rollouts. - Pilot a new version at one scope while production stays on the version it was tested against.
Rollback. - Point the assignment back at the previous version. Nothing to redeploy.
Visible history - Every version is preserved and viewable in the portal.
Version-aware compliance - Compliance records show which version produced them.

Getting started

Your existing definitions are already on 1.0.0. Every custom definition and initiative that existed before this rollout has been backfilled to version 1.0.0. Evaluation has not changed. You now have a starting point to iterate from.

Create a new version by setting properties.version to a higher number and saving. The previous version is preserved. For example, a custom "Allowed locations" policy that started at 1.0.0 with only westus2, and was widened to add two more regions. The example below treats that as a major bump to 2.0.0, but any higher version number works, see "Suggestion for version bumps." for guidance:

{ "properties": { "displayName": "Allowed locations (custom)", "mode": "Indexed", "version": "2.0.0", "parameters": { "allowedLocations": { "type": "Array", "defaultValue": [ "westus2", "eastus2", "centralus" ] } }, "policyRule": { "if": { "not": { "field": "location", "in": "[parameters('allowedLocations')]" } }, "then": { "effect": "deny" } } }, "type": "Microsoft.Authorization/policyDefinitions", "name": "allowedLocationsCustom" }

Assign a version with definitionVersion. Use 1.*.* to stay on major version 1 and pick up minor and patch changes automatically (recommended), or 1.1.* to pin to a minor version.

The patch position must always be *. Setting definitionVersion to a specific patch version such as 1.1.1 is not supported and the assignment will fail. Use 1.*.* or 1.1.* instead.

{ "properties": { "policyDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/policyDefinitions/allowedLocationsCustom", "definitionVersion": "1.*.*" }, "type": "Microsoft.Authorization/policyAssignments", "name": "allowedLocationsProd" }

To promote production to 2.0.0, change definitionVersion to 2.*.*. To roll back, change it again.

Check which version is in effect by adding $expand=latestDefinitionVersion,effectiveDefinitionVersion to a GET on the definition or assignment. See Policy Definition Versions REST API.

Portal

Custom definitions now behave like built-ins. The definition and assignment views show the version in Essentials with a Select version dropdown. Editing a definition shows a New version field next to the current one. The Create Assignment blade lets you choose which version to reference, and the compliance detail view includes a Version column.

CLI & PowerShell

Versioning is also supported in Azure CLI and Azure PowerShell. Create a new latest version with az policy definition create --version and manage older versions with the az policy definition version command group. See the Azure CLI reference and Azure Powershell reference for full examples.

Suggestions on Version Bumps

Bump	Example	What Qualifies	Assignments pinned to 1..
Major	1.2.0 → 2.0.0	Breaking changes: significant rule logic changes, removing a parameter, adding an enforcement effect by default, adding an enforcing definition to an initiative	Not picked up until you move them
Minor	1.1.0 → 1.2.0	Non-breaking changes: small rule logic refinements, new allowed values, new parameters with defaults, roleDefinitionIds changes	Picked up automatically
Patch	1.2.0 → 1.2.1	Text and metadata only: display name, description, category	Always picked up, cannot be pinned

These are guidelines, not rules. Azure Policy doesn't check what changed between versions, so bump whichever number fits your process. Just remember that assignments on 1.*.* pick up minor and patch bumps automatically, but not major ones.

If you already track a version string in metadata.version, you can keep it, but Azure Policy does not act on it. Use properties.version going forward.

Important items to note

Version Limit - Each custom definition or initiative can hold up to 4 versions during public preview. Delete unassigned versions to make room. A version cannot be deleted while an assignment references it.
New versions must be higher - than the version you are editing from and cannot collide with an existing version.
Supported modes - Custom versioning is supported for mode, All and Indexed. Resource Provider modes are not supported yet.
Version overrides - on assignments (policyVersion override kind) are available for built-ins only. They are not supported for custom definitions or initiatives.
Patch pinning - is not supported. Patch changes are always ingested, the same as built-ins.

What's next

We are working on Resource Provider mode support and a side-by-side version comparison in the portal.

Resources

Automating Compliance Scope Enforcement with Azure Policy

gurjsing — Wed, 02 Sep 2026 00:08:55 GMT

Cloud compliance certifications like C5, ISO 27001, HIPAA, or PCI DSS never cover the whole platform. They only cover a defined set of services, listed in an official document published by Microsoft. A common and costly mistake is to assume that “Azure is certified for X” automatically means every Azure service is covered. In reality, the list of covered services changes with every new document version, and it is often different for Azure Public compared to Azure Government.

Let's walk through this technically, step by step, using Microsoft's C5 (Germany) compliance offering as a concrete example. The same approach works for any other compliance standard that publishes a similar service-scope table — only the source document and the resulting parameter values change.

Within that C5 example, an even more common mistake goes one step further: "Azure is C5-certified, so my workloads are automatically C5-compliant." That is not true. C5 works on a shared-responsibility model. The customer still has to set up things like:

🔐 RBAC and Privileged Identity Management (PIM)
🌐 Network Segmentation
📊 Logging & Monitoring
🔑 Key Management
💾 Backup & Recovery Concepts

One thing almost always gets missed on top of that: whether the Azure service itself is actually C5-certified in the first place. Across numerous Landing Zone assessments🔍, this is consistently the point that gets overlooked. If a service isn't certified, it should be blocked as a resource type before anyone can even deploy it - which is exactly the process we walk through next.

🛠️A Five-Step Approach

📄Step 1 - Identify the Authoritative Source

For C5, Microsoft publishes an "Azure Compliance Offerings" document (Service Trust Portal). It has two appendices listing exactly which services are covered for Azure Public and for Azure Government - and the two lists are not the same.

📑Step 2 - Extract the Scope Data in a Structured Form

This document is published as a PDF, with the actual data laid out as tables: services listed against certification columns. Instead of typing rows into a spreadsheet by hand, there are a few practical ways to turn that into structured data. A small one-time script (for example, using a PDF text-extraction library) is the most repeatable option, but a tool like Microsoft 365 Copilot can also read the table directly out of the PDF and export it as CSV or JSON, which is a fast alternative if nobody on the team wants to write or maintain a script.

Either way, the goal is the same: end up with a structured CSV or JSON file, not a static PDF, since that file becomes the single source of truth for everything that follows. The real benefit shows up the second time: when a new document version comes out, redoing the extraction gives a clean diff showing exactly which services were added or removed.

Below is an example of how that extract can look once it's structured - two services from the August 2026 document that are not part of the Germany C5 scope, each mapped to its actual Azure resource provider and resource types:

{ "NonAllowedResources": [ { "name": "Azure Kubernetes Fleet Manager", "resourceProvider": "Microsoft.ContainerService", "resourceTypes": ["fleets"] }, { "name": "Azure Storage Actions", "resourceProvider": "Microsoft.StorageActions", "resourceTypes": [ "locations", "locations/asyncoperations", "locations/operationStatuses", "operations", "storageTasks", "storageTasks/reports", "storageTasks/storageTaskAssignments" ] } ] }

Note: In addition to a dedicated PDF-parsing script, the download-and-extract step can be handed off to an LLM entirely. A Foundry Agent (or a plain Azure OpenAI call) can be given a URL or file input, download the document itself via a connected tool/function, and return the extracted table directly as JSON matching the schema above.

⚖️Step 3 - Allow-List vs. Deny-List

An allow-list only permits certified services. For highly regulated environments, allow-lists are often preferred because they enforce an explicit "only what is approved" model. It is the stricter option, but harder to maintain, because most services in a mature platform are usually already certified. A deny-list only blocks the few services that are not certified, which is usually much easier to maintain, since that list is typically short. Which option makes sense still depends on your risk appetite and the specific requirement you're working with.

Note: in some cases, it isn't the whole service that's missing certification, just a specific sub-feature of it. A single entry in the source document can bundle several sub-services under one name, and they don't always share the same status. Treating the whole entry as one block, in either direction, can silently make your scope too strict or too loose - so it's worth checking the exact granularity in the source document rather than assuming a sub-service inherits its parent's status.

🧩Step 4 - Map to Azure Policy

Not every entry in a compliance document is something Azure Policy can act on, and the document doesn't flag the difference for you. Entries fall into two buckets: services that map to an actual, deployable ARM resource type, which Azure Policy can deny or audit directly, and entries that describe a portal feature or platform capability with no deployable resource behind them at all - for example, "Microsoft Azure Portal" or the "Quota+ Usage Blade", both listed in the same table. These entries therefore require different handling during the mapping process. The real effort in this step is sorting entries into these two buckets and, for the first one, translating business-facing service names into the exact resource type strings Azure Policy expects. Once that mapping exists, the policy definition itself is relatively straightforward.

Take the two entries from the Step 2 extract. Azure Kubernetes Fleet Manager flattens to a single resource type, Microsoft.ContainerService/fleets. Azure Storage Actions flattens to several, such as Microsoft.StorageActions/storageTasks and Microsoft.StorageActions/storageTasks/reports. Once every entry has been flattened this way, they all feed into the same parameterized deny policy

param policyName string = 'deny-out-of-compliance-scope-services' resource denyOutOfScope 'Microsoft.Authorization/policyDefinitions@2021-06-01' = { name: policyName properties: { displayName: 'Deny resource types outside approved compliance scope' policyType: 'Custom' mode: 'Indexed' parameters: { NonAllowedResources: { type: 'Array' metadata: { displayName: 'Excluded resource types' description: 'Resource types outside current compliance scope.' } } } policyRule: { if: { field: 'type' in: '[parameters("NonAllowedResources")]' } then: { effect: 'deny' } } } }

A practical governance model must balance control with flexibility. When teams need to evaluate new capabilities, such as preview services not yet covered by existing standards, policy exemptions provide a controlled exception mechanism. By requiring an expiry date, organizations can prevent temporary deviations from evolving into long-term compliance gaps.

resource temporaryExemption 'Microsoft.Authorization/policyExemptions@2022-07-01-preview' = { name: 'exemption-preview-service-evaluation' properties: { policyAssignmentId: assignment.id exemptionCategory: 'Waiver' displayName: 'Temporary evaluation of a non-certified preview service' description: 'Approved by security review on 2026-08-15; must be re-assessed before expiry.' expiresOn: '2026-11-15T00:00:00Z' } }

Note: A deny effect is a good default for new deployments, but not always for existing environments. For live workloads, start with audit mode to assess impact before enforcing deny. Consider the newer compliance substate for exemptions, which keeps exempted resources visible in compliance reporting instead of excluding them.

🔄Step 5 - Automate & Audit

Keep policy definitions and assignments as code, alongside the scope file from Step 2, in the same repository as the rest of your Landing Zone infrastructure. At a high level, this splits into two workflows: one that gets hold of the latest source document and regenerates the JSON scope file, and a second one that takes an approved change to that file and redeploys the policy assignment.

A key advantage of this approach is that the document retrieval process is isolated from the rest of the workflow. For this publicly accessible document, the workflow simply queries the Trust Portal API to obtain the latest version ID and then downloads the corresponding file.

name: sync-c5-compliance-scope on: schedule: - cron: '0 6 * * 1' # weekly check for a new compliance document workflow_dispatch: {} permissions: contents: write pull-requests: write jobs: extract-and-diff: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Download the compliance document (public doc, no auth needed) run: | DOC_ID="7adf2d9e-d7b5-4e71-bad8-713e6a183cf3" VERSION_ID=$(curl -s "https://api.servicetrust.microsoft.com/api/v2/GetLiveDocumentIncludingOldSeriesDoc/$DOC_ID" | jq -r '.id') curl -sS -o compliance-offerings.pdf "https://api.servicetrust.microsoft.com/api/v2/downloadDocuments/$DOC_ID/$VERSION_ID" - name: Extract current compliance scope run: python scripts/extract_c5_scope.py compliance-offerings.pdf --out compliance/c5-scope.json - name: Open a PR if the scope changed uses: peter-evans/create-pull-request@v6 with: title: 'Update C5 compliance scope' branch: update-c5-scope add-paths: compliance/c5-scope.json

The second workflow runs only after approval and merge into the main branch. It leaves the extraction process untouched, instead translating the domain-based JSON from Step 2 into the flattened resource type array required by Azure Policy and redeploying the assignment defined in Step 4 with the updated parameter set.

name: deploy-c5-policy on: push: branches: [main] paths: ['compliance/c5-scope.json'] permissions: id-token: write # required for OIDC federated login contents: read jobs: deploy-policy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: azure/login@v2 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Flatten the extract into the policy's parameter format run: | jq '[.NonAllowedResources[] | .resourceProvider as $rp | .resourceTypes[] | "\($rp)/\(.)"]' \ compliance/c5-scope.json > excluded-resource-types.json - name: Redeploy policy assignment with updated scope run: | az deployment mg create \ --management-group-id ${{ vars.MG_ID }} \ --template-file infra/policy-assignment.bicep \ --parameters excludedResourceTypes=@excluded-resource-types.json

The key benefit of this design is the strict separation between change generation and change deployment. The extraction workflow is limited to creating reviewed pull requests, while the deployment workflow acts solely on approved and merged content. This guarantees that no unreviewed modification can reach a production policy assignment, and that safeguard remains in place regardless of how the underlying document is sourced.

There are plenty of other ways to implement this - the following are just meant as inspiration:

Someone downloads the public PDF into a storage account container. The GitHub workflow is then triggered manually, fetches the PDF from blob storage instead of the Trust Portal API, and continues as normal from there (extraction → diff → PR).
Instead of doing this through workflows at all, a Logic App could just as well be the preferred choice, handling these exact same steps end to end on its own.

🎯Compliance as Code, Not Compliance as Spreadsheet

Any list you hardcode will go out of date, sooner or later. A process that re-reads the list whenever needed stays correct indefinitely. The C5 document is a good example of why: the same service can be certified for Azure Public but not for Azure Government, or the other way around. That's a good reminder that the extraction step needs to be repeatable, not something you do once during a single audit.

✅ The real objective is not maintaining a perfect list.

✅ The objective is maintaining a repeatable process that continuously converts Microsoft's published compliance scope into enforceable controls.

[Now Generally Available] What-If for Azure Deployment Stacks

torreyt — Tue, 18 Aug 2026 15:20:36 GMT

We are proud to announce that what-if for Azure Deployment Stacks is now generally available, in all regions.

To be precise about what this is, since the names are similar: what-if for standard template deployments has been around for a while. This release brings what-if to the deployment stacks resource type. A Stacks What-if result is composed of the list of change types (e.g. create, modify, delete, etc.) and their corresponding resources, the changes to the stack resource itself (e.g. changes to deny settings of a stack), and lastly the changes to the resources a stack manages (e.g. managed resources to be detached or deleted).

Furthermore, the new Stacks What-if filters out "noise" (noisy properties that are flagged by what-if as changes that are false positives) by using a baseline recorded when the stack was deployed. And the result it produces is a Stacks What-If Resource you name and can retrieve later, rather than output that disappears when your terminal scrolls.

This is the most requested feature we have had for deployment stacks. Thank you to everyone who kept that conversation going. This release is a direct result of it.

Why this matters

Deployment stacks manage a collection of resources as a single unit. With deployment stacks, users are able to perform a single delete operation on the stack that is applied to all of its managed resources rather than having to go one-by-one or scope-by-scope to perform that delete. More surgically, a user can also choose to delete a subset of managed resources by removing their definition from the bicep or ARM template that defines the state of the stack. This capability is extremely powerful, and it is also what makes updating a stack feel risky. A change to your template does not just add or modify resources. Depending on the actionOnUnmanage setting, it can also remove resources from the stack's management, or delete them outright.

Until now, the only way to know for certain what a stack update would do was to run it. For teams running production estates on stacks, that is an uncomfortable place to be.

Stacks What-if answers the following questions before you deploy changes:

What is about to happen to my resources?

What resources will be deleted?

What is included

Stacks What-if at resource group, subscription, and management group scope, in Azure CLI, Azure PowerShell, and the Azure SDKs.
Detach and Delete changes, so you can see which resources are about to leave the stack's management or be removed from Azure.
Standard change types on managed resources, such as create, modify, and delete, including property level diff detail.
Noise reduction, enabled in all regions, for more accurate results, with false positives (aka noise) removed from the Stacks What-if response.
Stacks What-If Result as a New Resource Type, which you can reference by URI and use as an approval artifact in a pipeline.

What Stacks What-if reports

Stacks What-if evaluates your template against the current state of the resources the stack manages, and reports each one as a change type. It makes no changes to your resources.

Symbol	Change type	Meaning
`+`	Create	The resource doesn't exist and is created.
`~`	Modify	The resource exists and some properties change.
`=`	NoChange	The resource exists and isn't changed.
`-`	Delete	The resource is removed from the stack and deleted.
`v`	Detach	The resource is removed from the stack's management but isn't deleted from Azure.
`!`	Unsupported	The resource isn't supported for what-if evaluation.

That list is specific to stacks, and it is not the same set you get from deployment what-if. Detach and Delete are the two that matter most here (e.g. a resource you removed from your template is about to leave the stack's management, or be deleted outright), and they are the reason this feature exists. They tell you which resources are affected before you deploy, not after.

The one thing to know if you're coming from deployments

If you already use what-if for regular Bicep or ARM template deployments, there is one difference worth internalizing.

For a standard deployment, what-if is an operation. You run it, Azure returns the predicted changes, and nothing persists.

For a deployment stack, Stacks What-if creates a Stacks What-If Resource, which stores the Stacks What-If response. The result is a standalone Azure resource of type Microsoft.Resources/deploymentStacksWhatIfResults. You give it a name, it gets its own resource ID, and it references the stack it was evaluated against through properties.deploymentStackResourceId.

That means a Stacks What-If Resource ID looks like this:

/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Resources/deploymentStacksWhatIfResults/{what-if-result-name}

Get started running Stacks What-if

Azure CLI, at resource group scope:

az stack-whatif group create \
  --name "my-preview" \
  --resource-group "my-rg" \
  --stack-id "/subscriptions/<sub-id>/resourceGroups/my-rg/providers/Microsoft.Resources/deploymentStacks/my-stack" \
  --template-file "main.bicep" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Azure PowerShell:

New-AzResourceGroupDeploymentStackWhatIfResult `
  -Name "my-preview" `
  -ResourceGroupName "my-rg" `
  -StackResourceId "<stack-resource-id>" `
  -TemplateFile "main.bicep" `
  -ActionOnUnmanage "DetachAll" `
  -DenySettingsMode "None" `
  -RetentionInterval "PT3H"

Real output from a Stacks What-if run against a demo stack. The legend maps each symbol to a change type, then each managed resource is listed with the property changes underneath it:

Subscription and management group scopes work the same way, using az stack-whatif sub and az stack-whatif mg, or the New-AzSubscriptionDeploymentStackWhatIfResult and New-AzManagementGroupDeploymentStackWhatIfResult cmdlets.

A detail that is easy to miss: the stack does not have to exist yet. If it doesn't, Stacks What-if reports the stack itself as a new resource, so you can preview the very first deployment of a stack before you create anything.

Using it in a pipeline

The durability of a Stacks What-If Resource is what makes this useful in CI. A pattern that works well:

On a pull request, run Stacks What-if against the target stack and give the result a name that includes the build or PR number.
Post the output, or a link to the result, as PR feedback so a reviewer sees the predicted changes next to the template diff that caused them.
Gate the deploy stage on approval. If someone wants to re-check before approving, they retrieve the same stored result rather than rerunning the evaluation and hoping it matches.

Point 3 is the part that's genuinely different. With deployment what-if you get output in a log, and if you want it again you rerun and hope nothing drifted underneath you. With a Stacks What-If Resource you retrieve the exact evaluation the reviewer looked at.

Set the retention interval to cover your review window and no longer. PT3H gets cleaned up for you, so it's a good default for per pull request runs.

Resources

Preview deployment stack changes with what-if. The documentation for what is being announced here. Change types, running Stacks What-if at each scope, retrieving and deleting Stacks What-If Resources, and noise reduction.
Create and deploy Azure deployment stacks in Bicep. The main deployment stacks article, if you are new to stacks or want a refresher on actionOnUnmanage.
Preview Bicep deployment changes by using what-if. What-if for standard template deployments. This is the separate, existing feature described earlier, included here for comparison rather than as part of this release.

Tell us what you think

This feature exists because people filed issues and kept talking to us about them. That has not changed. If Stacks What-if reports something that looks wrong, or the output is awkward in your pipeline, open an issue in Azure/deployment-stacks. We read them, and several are already shaping what we do next.

Introducing Compliance Substate for Azure Policy Exemptions!

stevenbucher — Tue, 28 Jul 2026 23:26:47 GMT

When a policy is applied, some resources in scope may need to be temporarily exempted from enforcement, whether it be during a migration, an incident, or while an app team works through its compliance requirements.

However, the moment you grant an exemption, that resource's compliance result flips to “Exempt” and that's all you see. The underlying state is hidden behind the exemption. This leads to questions like, is the resource violating the policy right now? Or has it quietly come into compliance since the exemption was granted, and can I safely remove the exemption? The “Exempt” status alone can't tell you.

To solve this, we've introduced a new compliance substate property on Azure Policy compliance results. This property tells you what the resource's compliance state would be if the exemption were removed so you never lose sight of the underlying state.

Before and after

Before: Your compliance report lists 40 resources, all showing "Exempt" and nothing more. You have no idea which exemptions still matter, so you either leave them all in place or audit each one by hand.
After: The same 40 resources still show Exempt, but now each carries a substate - 28 Compliant (safe to retire) and 12 non-compliant (still needed). Your cleanup list just wrote itself.

How to see the sub-state

The primary way you will interact with Compliance Substate is right where you already review compliance today, the Compliance tab of the Azure Policy blade. It surfaces as an optional column in the resource compliance table of an assignment's compliance report.

How to show the Compliance Substate column

Open the assignment's compliance report. In the Azure portal, go to Policy > Compliance, then open the report of the assignment you want to view.
Click on the “Edit Column” button to edit which columns are shown by default.

3. Add the new property. In Edit Options, add a new property and select the “Compliance sub state” and then select save. You can drag to reorder the columns.

4. Read the results. Exempt resources now show Compliant or Non-compliant. Non-exempt resources show blank for compliance substate.

Additionally, you can click on the “Waiver” or "Mitigated" status under the "Compliance details" column and the details tab will include the compliance substate by default.

Querying the property

The portal column is perfect for reviewing a single assignment. For org wide exemption audits you will want to query across every subscription at once. Compliance Substate is also surfaced in Azure Resource Graph (ARG) under properties.stateDetails.complianceSubState, so you can build reports, dashboards, and automation on top of it.

The core query. List every exempted resource and its substate:

policyresources | where type == "microsoft.policyinsights/policystates" | extend complianceState = tostring(properties.complianceState) | extend complianceSubState = tostring(properties.stateDetails.complianceSubState), resourceId = tostring(properties.resourceId), policyAssignmentId = tostring(properties.policyAssignmentId) | where complianceState == "Exempt" | project resourceId, policyAssignmentId, complianceState, complianceSubState

Conclusion

Exemptions will always be part of governance, but they no longer have to be a blind spot. Compliance Substate shows you what is really happening underneath every exemption, so you can remediate resources, confirm they are green, and retire exemptions with confidence instead of guesswork. Give it a try and let us know what you think by sharing your thoughts to policypm@microsoft.com!

Other resources

Introducing Kubernetes-Native Policy Validation with CEL and VAP in Azure Policy

stevenbucher — Thu, 23 Jul 2026 19:27:12 GMT

Azure Policy for Kubernetes now supports Gatekeeper’s integration with native Kubernetes Validating Admission Policy (VAP) using Common Expression Language (CEL)! This integration leverages the new VAP feature introduced in Kubernetes 1.30, providing a more efficient, reliable and in-process way to enforce policies.

This integration brings lower latency for admission decisions, simpler constraint template authoring—for the first time – allows you to enable stronger fail-close behavior to prevent non-compliant components getting created or updated in your environment . And you keep all the Azure Policy benefits you already rely on like centralized assignment, scope management, safe rollout control, and governance at scale.

Previously, Azure Policy for Kubernetes only supported on OPA Rego-based evaluation through an admission webhook flow:

A request is sent to the Kubernetes API server.
The request is forwarded to Gatekeeper.
Gatekeeper enforces resources using constraint template written in Rego.
The result is returned to the API server.

Native Kubernetes Validation with Common Expression Language (CEL)

Policy expressions can be written in CEL syntax, a lightweight and expressive language that Kubernetes designed specifically for this validation context. Here's what changes:

In-tree evaluation: Policy rules run inside the Kubernetes API server itself, not in an external webhook service. This means:
Lower latency: No round-trip delay to an external service. Admission decisions are made faster because evaluation happens in-process.
Better reliability: Validation doesn't depend on a separate service remaining healthy. If the VAP controller finds a violating resource, the PUT request will be denied, resulting in a fail-close scenario.

Getting Azure Policy Benefits with CEL

Kubernetes-native enforcement does not replace Azure Policy governance capabilities. It strengthens them. Azure Policy becomes the governance and deployment layer, while CEL becomes the validation logic. Here's what that means:

CEL handles the validation: You write lightweight, readable expressions that run natively in Kubernetes. CEL is simpler than Rego and aligns with Kubernetes' own validation framework.
Azure Policy handles the governance: Assignments, versioning, compliance tracking, safe rollouts, overrides, and multi-cluster management all happen through Azure Policy. You get enterprise governance without extra operational overhead.

Your First CEL Policy with Azure Policy

Here's the key insight: you don't write Azure Policy definitions in CEL. Instead, you write a CEL constraint template, package it inside an Azure Policy definition, and deploy it through Azure Policy.

Think of it as two layers:

Layer 1: CEL Constraint Template — The Kubernetes validation logic you write
Layer 2: Azure Policy Definition — The wrapper that adds assignments, versioning, compliance tracking, and safe deployment

Real Example: Limit Deployment Replicas

Let's walk through a concrete scenario. Your platform team wants to prevent developers from creating Deployments with more than 5 replicas—a common guard rail for dev/test environments to control resource consumption.

- replicas: 1 through replicas: 5 — allowed

- replicas: 6 or higher — denied

Step 1: Write the CEL constraint template

You write a Gatekeeper ConstraintTemplate using the K8sNativeValidation engine. The CEL expression itself is a single, readable line:

apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8se2etestcelmaxdeployreplicas spec: crd: spec: names: kind: K8sE2ETestCelMaxDeployReplicas validation: # Schema for the `parameters` field openAPIV3Schema: type: object properties: message: type: string targets: - target: admission.k8s.gatekeeper.sh code: - engine: K8sNativeValidation source: validations: - expression: "object.spec.replicas <= 5" message: "message example"

The key part is the engine: K8sNativeValidation block. This tells Gatekeeper to generate a Kubernetes ValidatingAdmissionPolicy resource from this template, so evaluation runs inside the API server rather than through the Gatekeeper webhook. The CEL expression object.spec.replicas <= 5 is evaluated natively at admission time.

Step 2: Package the CEL template into an Azure Policy definition

You then will need to base64-encode the constraint template (you can use an online tool or a local tool to do this) and embed the encoded content in an Azure Policy custom definition using sourceType: Base64Encoded. The full custom policy definition structure, matching the real format Azure Policy expects:

{ "policyType": "Custom", "mode": "Microsoft.Kubernetes.Data", "displayName": "Ensure deployment replicas are less than or equal to 5 in Kubernetes cluster", "policyRule": { "if": { "field": "type", "in": [ "Microsoft.ContainerService/managedClusters" ] }, "then": { "effect": "[parameters('effect')]", "details": { "templateInfo": { "sourceType": "Base64Encoded", "content": "<BASE64_ENCODED_CONSTRAINT_TEMPLATE>" }, "apiGroups": [ "apps" ], "kinds": [ "Deployment" ], "namespaces": "[parameters('namespaces')]", "excludedNamespaces": "[parameters('excludedNamespaces')]", "labelSelector": "[parameters('labelSelector')]", "values": { "message": "[parameters('message')]" } } } }, "parameters": { "effect": { "type": "String", "allowedValues": [ "audit", "deny", "disabled" ], "defaultValue": "audit" }, "namespaces": { "type": "Array", "defaultValue": [] }, "labelSelector": { "type": "Object", "defaultValue": {} }, "message": { "type": "String" } } }

A few things worth noting in this structure:

sourceType: Base64Encoded - Azure Policy stores your constraint template as base64 content inline in the policy definition. When Azure Policy deploys to your cluster, it decodes and installs the template automatically.
apiGroups: ["apps"] and kinds: ["Deployment"] - These scope the policy to only evaluate Kubernetes Deployment resources in the apps API group. Pods, Services, and other resources are unaffected.
excludedNamespaces - System namespaces like kube-system and gatekeeper-system are excluded by default, so the policy doesn't interfere with cluster infrastructure.
effect: audit (default) - The policy starts in audit mode, flagging violations without blocking them. Switch to deny when you're ready to enforce.

Right now only audit, deny, and disabled Policy effects are supported.

You can create the policy definition via the Azure portal, Azure CLI, or the Azure Policy VS Code extension.

Step 3: Assign the policy to your AKS clusters

Now you can assign this policy through Azure Policy to your clusters:

In the Azure portal, go to Azure Policy > Definitions.
Find your policy by name (e.g., "Ensure deployment replicas are less than or equal to 5").
Click Assign.
Set the Scope to the management group, subscription, or resource group containing your AKS clusters.
Set the effect parameter to audit to start, then graduate to deny once you've validated the policy behavior.
Click Create.

Azure Policy deploys the CEL-based constraint template to all clusters in scope. Within a few minutes, the Azure Policy add-on decodes the template, installs it on each cluster, and Gatekeeper generates the corresponding ValidatingAdmissionPolicy resource. From that point on, the Kubernetes API server evaluates every new Deployment admission request against your CEL rule directly. You can target different clusters or namespaces with different assignments and apply overrides for exceptions.

Step 4: Monitor compliance through Azure Policy

In the Azure Policy console, you see real-time compliance across all your clusters:

Non-compliant Deployments (those with replicas > 5) appear in the Compliance view.
You can drill down by policy, cluster, or namespace to see which Deployments are violating the limit.
While in audit mode, existing violations are surfaced without blocking anything—giving you a clear picture before switching to deny.

Availability and prerequisites

Supported Kubernetes version: AKS clusters running Kubernetes v1.30 or later (VAP became generally available in K8s v1.30).
Gatekeeper version: Azure Policy add-on includes Gatekeeper v3.17.0 or later, which supports VAP and CEL policy generation.
Azure Policy Add-on: The Azure Policy add-on for Kubernetes must be installed on your clusters. See Azure Policy for Kubernetes documentationfor installation instructions.

This is currently generally available and can be used to enforce policies in your Kubernetes clusters today.

Roadmap

We are actively working to include more built in Azure Policies for Azure Kubernetes service with the constraint template built with CEL.

Resources

Azure Policy for Kubernetes: Full documentation on how Azure Policy integrates with Kubernetes, including built-in definitions and assignment workflows.
Common Expression Language in Kubernetes: Reference guide for authoring CEL expressions used in Validating Admission Policies.

Conclusion

Azure Policy for Kubernetes now lets you bring Kubernetes-native CEL validation into your enterprise governance workflow.

The mental model is simple: CEL handles what to validate, Azure Policy handles how to govern it. You write clean, readable CEL expressions that run natively in your Kubernetes API server. Azure Policy wraps those expressions and handles the hard parts of enterprise governance—assignments across management hierarchies, versioning, compliance tracking, safe rollouts, and overrides.

Whether you're enforcing container registries, requiring security contexts, or validating resource configurations, you now have a path to do it natively in Kubernetes with enterprise governance backing it up.

Azure landing zone (ALZ) enters its next chapter

jtracey93msft — Tue, 28 Jul 2026 10:22:02 GMT

Azure landing zone (ALZ) is now maintained by the Azure Migrate team. Nothing has changed in relation to getting support and making requests; still head to aka.ms/alz/issues (GitHub) and file your ask.

ALZ continues to be open-source, maintained by the Azure Migrate team 👍

This is only the Platform landing zone side, where ALZ operates as detailed here Platform landing zone vs. application landing zones

Hey all 👋

I’ve got a genuinely exciting update to share today, and it’s one that’s been a long time coming: Azure landing zone (ALZ), maintained by the Azure Migrate product team.

A bit of history first

For the past five or so years, ALZ has been built completely in the open, in the open source repos, in community calls, in issues, in PRs, together with an incredible group of customers, partners, and Microsoft folks who cared enough to keep showing up and making it better. This has helped many customers start their Azure Journey with the right Platform landing zone. That community effort is the entire reason ALZ is what it is today, and it deserves a moment of recognition before we talk about what’s changing.

So, what’s actually changing?

ALZ continues to remain community driven, open source initiative now maintained by Azure Migrate team.

For you, practically? Nothing changes. The GitHub repos, the modules, the way you consume ALZ today all stay exactly as they are. So that you can continue to deploy high-quality Platform landing zones for you and your customers.

What’s changing is who’s steering the ship. If you’ve got an issue to raise, that still happens exactly where it always has, over at aka.ms/alz/issues.

What about us?

I want to be upfront about this part: myself (Jack Tracey), Matt White, Jared Holgate, and Zach Trocinski are no longer involved in the day-to-day of ALZ. No more issue triage, no more day-to-day operations from us. That responsibility now sits with the Azure Migrate team.

We’re not disappearing entirely, though. Over the last couple of months we’ve been running a proper handover, and we’ll continue to be around behind the scenes for those moments when the Azure Migrate team needs a bit of extra context we didn’t manage to pass on during that process.

And honestly? You’re in great hands. The Azure Migrate team already know ALZ inside and out. They’ve been working alongside us building the Azure Migrate agent’s platform landing zone creation experience, which uses ALZ under the hood. This isn’t a handover to strangers, it’s a handover to people who’ve already been in the engine room with us.

A personal thank you

Before I move on, I wanted to add something a bit more personal.

ALZ is one of the things I’m proudest of from my time at Microsoft so far. I’ve built and led it over the past five or six years, surrounded by genuinely great people who helped shape it, and backed by an amazing community, customer, and partner base who supported us every step of the way to make it the success it is today.

So, while I’m stepping away and I’m no longer involved in the day-to-day, ALZ will always hold a special place for me. I’ll forever be happy to chat about it socially. It’s something I still have real passion for, and that’s not going away just because my day job has moved on.

That said, I’m taking those learnings and that passion into other things at Microsoft, including now focusing on AVM (Azure Verified Modules) alongside Jared and several other great folks. We’ll have some announcements of a similar nature to share on that front soon, so watch this space 😁

Thank you 🙌

And finally, the wider thanks. Alongside Matt White, Jared Holgate, and Zach Trocinski, huge thanks to: Paul Grimley, Rob Kuehfus, Sacha Narinx, Seif Bassem, Arjen Huitema, Nelson Pereira, Paulo Alves Oliveira Jr., Vishal Mehrotra, Charlie Grabiaud, Simona Tarantola, Bruno Gabrielli, Luke Taylor, Adam Tuckwell, and Kevin Rowlandson.

A special shout-out too to Remo Leone Laudo, Rhys Ash, Jamie Pla, Igor Jovovic, and Haflidi Fridthjofsson, who will continue to contribute to the ALZ IaC modules alongside their day jobs as CSAs, as and when they can 🙂

And to everyone else who’s contributed to ALZ over the past five years or so, through code, issues, feedback, conversations, or just using it and telling us what worked and what didn’t, thank you. This milestone is yours as much as anyone’s.

Here’s to the next chapter for ALZ. 🎉

ARM MCP Server: A Catalog of 24 PoCs

varghesejoji — Fri, 19 Jun 2026 16:57:26 GMT

Introduction

The Azure Resource Manager MCP Server is a remote Model Context Protocol server that gives AI agents first-class access to Azure infrastructure operations. Six tools is a small surface area, but ARM and Azure Resource Graph are not small control planes. To explore what that surface area can support in practice, we built the arm-mcp-poc-catalog: 24 self-contained proof-of-concept agents spanning enterprise governance, FinOps, platform engineering, and Site Reliability Engineering.

This post is in two parts. Part 1 summarizes what the ARM MCP Server offers. Part 2 walks through the catalog and how to use it.

Part 1. What the ARM MCP Server Offers

Architecture

The ARM MCP Server is a remote MCP server hosted at https://mcp.management.azure.com. There is no container to run, no sidecar to deploy, and no service principal to manage. Every operation executes in the context of the signed-in Azure user, so the agent's effective permissions are exactly the human's effective permissions, for both reads (ARG) and writes (ARM template deployments). Azure Policy assignments apply identically.

The six tools

#	Tool	Half	Purpose
1	generate_query	Read	Translate a natural-language ask into Azure Resource Graph KQL.
2	validate_query	Read	Statically validate an ARG query before execution.
3	execute_query	Read	Run an ARG query against the signed-in user's scope.
4	create_template_deployment	Write	Submit an ARM template to a target resource group.
5	get_arm_template_deployment_status	Write	Poll a deployment's progress, outputs, and errors.
6	cancel_arm_template_deployment	Write	Abort an in-flight deployment.

The toolset partitions cleanly into a read half (Azure Resource Graph) and a write half (Azure Resource Manager). The two halves compose: an agent can read the current state of the estate, decide what to change, deploy a template, and watch the result, all in a single conversation.

Why this matters

Three properties make the ARM MCP Server qualitatively different from earlier "Azure SDK in a function" approaches:

Identity inheritance. The agent operates as the user. There is no shared credential, no over-privileged service principal, and no escalation path from "the agent can read this" to "the agent can write that."
Tenant-wide read in one query. Azure Resource Graph indexes every resource type across every subscription the user can see. A single execute_query call can return all storage accounts in the tenant, or every public IP, or every VM by SKU, in seconds.
Deterministic write surface. ARM templates are declarative, idempotent, and auditable. Every create_template_deployment produces a correlation ID and an entry in the activity log. The agent inherits all of that for free.

Together, these properties move the practical question from "can we let an agent touch our cloud?" to "what is the most useful thing to put on top of these six tools?" That is the question the PoC catalog tries to answer.

Part 2. The PoC Catalog

The arm-mcp-poc-catalog is a public repository containing 24 proof-of-concept agents, organized into two batches of 12. Every PoC is a self-contained VS Code workspace with its own agent persona, deterministic skill, pre-canned ARG queries, frozen output templates, and ARM template stubs where applicable. Each PoC folder contains a README.md, a runbooks/ directory with a committed scope template and a gitignored values file, and the agent definition plus rules and output templates.

The determinism contract

Before walking through the catalog, one design decision is worth calling out because it shows up in every PoC. The ARM MCP Server's generate_query tool is non-deterministic: the same prompt can produce slightly different KQL on different invocations, which produces different result sets, which would produce different remediation actions in a recurring agent.

To make these PoCs safe for repeated use (weekly reports, on-call playbooks, pre-deploy gates), every PoC follows the same five-rule contract:

ARG queries are read literally from a rules.yaml file, never authored by the LLM at runtime.
Every query call is validate_query then execute_query. Failed validations are marked INVALID and the agent does not retry or rewrite.
Scope filters (subscription IDs, resource group names) are string-substituted from a separate values file.
Output is a frozen markdown template with {{placeholder}} slots. No paraphrasing by the model.
Run IDs follow <POC-PREFIX>-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]}, so identical inputs produce identical IDs.

The generate_query tool is still useful, but as a dev-time aid for drafting the KQL that gets checked into rules.yaml, not as a runtime step in a recurring agent.

Catalog: Enterprise PoCs (governance, FinOps, platform)

#	PoC	Primary tools	What it does
1	Tag Hygiene Czar	Read + Write	Finds resources missing required tags, generates a patch ARM template, deploys on approval.
2	Blast Radius Analyzer	Read + What-if	Pre-deploy: cross-references an ARM template against current state to predict create/modify/replace/delete impact.
3	Cost Driver Finder	Read	Surfaces top cost-driving resources by region/owner/workload using ARG topology and tags.
4	Golden Path Provisioner	Read + Write	Templated provisioning of standard workload patterns with policy-aware defaults.
5	IaC Drift Detector	Read	Compares deployed state to a Git-stored ARM/Bicep baseline and reports drift.
6	Incident Responder	Read + Write	Estate-wide impact assessment for a declared incident, with optional remediation deploys.
7	Policy What-If	Read	Simulates a proposed Azure Policy assignment against current resources to predict denials.
8	Estate Cartographer	Read	Generates a tenant-wide topology map (resources, dependencies, ownership) from ARG.
9	ARM Template Fixer	Read + Write	Diagnoses a failed deployment, proposes a corrected template, redeploys on approval.
10	Crown-Jewels Security	Read	Identifies the small set of high-value resources (Key Vaults, prod databases, identities) and their exposure.
11	FinOps Rightsizer	Read	Recommends SKU downshifts for under-utilized compute and data resources.
12	ChatOps Bot	Read + Write	Slack/Teams-friendly wrapper exposing a curated subset of agent verbs to non-engineers.

Catalog: SRE PoCs (incident response, change safety, reliability)

#	PoC	Primary tools	What it does
1	Incident Triage	Read + Cancel	"First 60 seconds" change feed for the affected scope, with one-key cancel for in-flight deploys.
2	Change Freeze Enforcer	Read + Write gate	Intercepts deployments during freeze windows; requires break-glass justification logged to ticketing.
3	Pre-flight Safety	Read	Battery of health/dependency/capacity checks before any prod deployment.
4	Auto Rollback	Write + Cancel	Watches a deploy; on failure or health-gate breach, cancels and applies last-known-good template.
5	Reliability Posture Scorecard	Read	Weighted scoring of ~15 reliability rules (zone redundancy, geo-replication, soft-delete, etc.) across a scope.
6	SLO Deployment Gate	Read	Blocks deploys when the target service's error budget is exhausted.
7	Capacity / Quota Guardian	Read	Tracks subscription/region quota headroom and warns before deploys would exceed it.
8	Blast Radius Simulator	Read	"What if I drained this AZ?" or "what if this RG went away?" dependency simulation.
9	Stuck Deployment Janitor	Read + Cancel	Finds deployments stuck in Running past their SLA, summarizes, optionally cancels.
10	Runbook Executor	Write	Parameterized ARM-template runbooks for routine ops (cert rotation, scale events, etc.).
11	Post-Incident Reconstructor	Read	Reconstructs an exact timeline of resource changes during an incident window for the postmortem.
12	Weekly Cleanup PRs	Read + Write	Generates PRs for low-risk cleanup (orphaned NICs, unused public IPs, untagged dev resources).

SRE-PoC-5 (Reliability Posture Scorecard) is the reference implementation. Read it first to understand the determinism contract end to end: literal KQL, validate then execute, frozen template, deterministic run ID, and no deployment risk.

Patterns that emerged across the 24 PoCs

Three patterns showed up repeatedly and are worth naming.

Pattern 1: Read-only agents are 80% of the value and 5% of the risk. Tag hygiene reporting, blast-radius analysis, cost driver discovery, crown-jewels security posture, the reliability scorecard, post-incident reconstruction: none of these require the write half of the API. They turn ARG into a query layer the existing humans can interrogate in English. Most teams should start here.

Pattern 2: Write-capable agents need three things, not one. Every deploy-capable PoC in the catalog gates create_template_deployment behind (a) an explicit user verb such as apply or remediate, (b) a confirm step that shows the resolved template and scope, and (c) a global freeze flag in the scope config that is checked before any other logic runs. The change-freeze enforcer (SRE-PoC-2) is itself one of the PoCs and can be wired in front of any other write-capable agent.

Pattern 3: The "what changed" loop is the killer feature. ARG can answer "what does my estate look like right now?" in seconds. Pair that with deployment status polling and you get "what just changed, by whom, and is it still in flight?", which is the foundation for incident triage, post-incident reconstruction, auto-rollback, and the stuck-deployment janitor. None of these were practical before the MCP server collapsed the auth, ARG, and ARM client stack into a single tool surface.

Getting started with any PoC

Install the ARM MCP Server once: open https://aka.ms/JoinARMMCP in VS Code and sign in.
Verify Azure access with az login. Read-only PoCs need Reader plus Resource Graph Reader on the target scope. Deploy-capable PoCs additionally need Contributor on the target resource groups.
Clone the catalog: git clone https://github.com/jvargh/arm-mcp-poc-catalog.git.
Open one PoC folder in VS Code as a workspace. The .vscode/mcp.json declares the ARM MCP server at workspace scope and starts it on first chat use.
Configure scope: copy runbooks/<scope>.values.yaml.example to runbooks/<scope>.values.yaml and fill in subscription ID and resource groups. The values file is gitignored.
Invoke the agent: see each PoC's README.md for accepted verbs (typically run, drilldown, remediate).

Spotlight: SRE-PoC-5, Reliability Posture Scorecard

Of the 24 PoCs in the catalog, the Reliability Posture Scorecard (SRE-PoC-5-Reliability-posture-scorecard/) is the reference implementation. It is the simplest PoC that exercises the full determinism contract end to end without any deployment risk.

What it does

The agent loads a fixed pack of weighted reliability rules from rules.yaml: checks like App Services without zone redundancy, SQL databases without geo-replication, Storage accounts without soft delete, and Key Vaults without purge protection. For each rule it calls validate_query then execute_query against the configured scope, aggregates failures per workload (resource group by default, or any tag), and computes a score:

score = max(0, 100 - Σ weight of failed rules)

The output is a frozen markdown report with a deterministic run ID of the form RPS-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]}. Run it twice in a row against the same scope and you get byte-identical output. Run it next week and any diff is a real change in the estate.

Why ARM MCP is a good fit

One tool covers every resource type. Reliability rules span App Services, SQL, Storage, Key Vault, NSGs, and more. ARG exposes all of them as columns in the same query language, so a 12-rule pack is 12 KQL strings instead of 12 SDK clients.
Tenant breadth in one round-trip. A single execute_query inspects every resource of a type in scope in seconds, with no pagination loop and no rate-limit gymnastics.
Identity inheritance keeps scoring honest. The agent can only score what the operator can see. No scoring service principal needs tenant-wide read.
Read-only, so it's safe to roll out first. Reader plus Resource Graph Reader is the entire permission requirement, which makes it the natural proof point before introducing any deploy-capable agent.

Resiliency benefits

Continuous, not episodic. Replaces the every-six-months Well-Architected Review with a weekly run that produces a 0–100 score per workload and a trend row in exports/scorecard-trend.csv.
Real diffs, not query drift. Deterministic run IDs mean a score moving from 78 to 64 is a real regression, not a different mood from the model.
Pre-launch gate. The same rule pack runs in dev, staging, and prod, so missing zone redundancy or backup configuration is caught before promotion, not after.
Postmortem evidence. The morning's scorecard is on disk with the exact failing rules and resource IDs, ready to cite directly in the writeup.
Cheap to extend. Adding a rule is one block of YAML (literal KQL, weight, severity, remediation hint). No agent code changes, no prompt engineering.

The full walkthrough, including the multi-step end-to-end flow from chat prompt through MCP to rendered report, is in the PoC's own README.

Conclusion

The ARM MCP Server's six tools are deliberately small. The interesting engineering is in the shape you wrap them in: how you trade off the model's flexibility against the determinism a recurring agent needs, how you gate writes, and how you compose ARG reads with ARM deploys to answer the questions a human operator actually asks.

The arm-mcp-poc-catalog is one set of answers to those questions. Twenty-four PoCs is a starting menu, not a roadmap. Pick the one closest to a problem your team has on Monday morning, read its README.md, run it against a non-prod subscription, and decide whether the shape fits before you commit to building your own.

If you build something interesting on top, please open an issue or a PR on the catalog repo.

References

Introducing the Azure Resource Manager MCP Server, Steven Bucher, Azure Governance and Management Blog
Azure-Resource-Manager-MCP on GitHub: official server repo and documentation
arm-mcp-poc-catalog: the 24-PoC catalog described in this post
ARM MCP Server install link

[Preview] CIS Benchmarks on Azure; Now for Windows Server

AmirB — Thu, 28 May 2026 23:33:29 GMT

For customers with machines managed by Azure (i.e., Arc-enabled machines and Azure VMs), last year we delivered built-in CIS Benchmarks for Linux. The feedback has been clear: “Excellent, now do Windows.”

Today we're announcing that built-in CIS Benchmarks for Windows Server are coming to Azure Policy and Machine Configuration as well.

Supported Edition: The initial preview supports Windows Server 2025 only. Additional Windows Server editions are planned for future releases.

Familiar workflow

If you've already adopted the new Machine Configuration catalog experience with CIS benchmarks for Linux, the Windows rollout will feel familiar.

Also consistent across Windows and Linux are:

Full parity with official CIS Benchmarks content - precision translation from CIS formats to Machine Configuration formats
Flexible configuration - adjust parameters, exclude settings
Compliance as code - your benchmark selections and customizations can be exported as JSON to support versioning, approval workflows, and even file-centric deployment patterns like GitOps, build pipelines, etc.
Single policy/assignment compatibility with Azure VMs and Arc-enabled machines); no need to handle Azure VMs one way and Arc machine another
Audit-first - Public Preview starts in audit-only mode; remediation and enforcement come next (see below).

Windows specifics

While we strive for consistency, we also strive to nail platform specific details. For instance, the new experience automatically handles heterogenous Windows fleet nuances such as:

Variation in CIS recommended settings by OS version (when available)
Variation in CIS recommended settings by role (domain controller, member server)
Variation in management APIs by OS version

What's next?

Beyond the current preview, we are focusing on:

Granular per-rule auto-remediation / enforcement so you can safely gradually increase security and compliance across your fleet
Retiring overlapping policy definitions in Azure; for example, unmaintained implementations of older CIS benchmarks, and so on
Adding STIG and other industry baseline coverage, so a single Azure control plane can manage your end-to-end compliance posture.

Get Started

Watch for aka.ms/cis-windows-azure to go live for enablement docs and resources.
In Azure Policy > Authoring > Machine Configuration, look for CIS benchmarks for Windows to appear as a built-in option.
Interested in the upcoming auto-remediation preview? See remediation preview sign-up form.

[Now Generally Available] Customizable Security Baseline Policies in Machine Configuration!

mutemwamasheke — Thu, 28 May 2026 19:29:06 GMT

Background: Azure Machine Configuration remains committed to enabling greater security and simplicity in at-scale server management for all Azure customers. Machine Configuration (previously known as Azure Policy Guest Configuration) enables both built-in and custom configuration as code allowing you to audit and configure OS, app, and workload level settings at scale, both for machines running in Azure and hybrid Azure Arc-enabled servers.

We're excited to announce the General Availability of Customizable Security Baselines in Azure Policy and Machine Configuration. What began as a Public Preview is now a mature, production-grade capability that empowers you to tailor industry security benchmarks to your organization's unique compliance standards across both Azure and Arc-connected machines, at scale.

This release moves the experience from "useful" to "everyday default." Standards coverage has expanded, the customization and assignment flow is faster, full lifecycle management is now possible directly from the Azure Portal, and a new Overview page gives you a single pane of glass into which parts of your estate are unprotected.

What is Baseline Customization?

The core experience remains: tailor security standards through the Modify Settings wizard under Policy > Machine Configuration. You can enable, exclude, or adjust rules from existing benchmarks, apply organization-specific parameters, and export your custom configuration as a downloadable JSON file. Each baseline JSON file serves as a reusable, declarative artifact, ideal for policy-as-code workflows, version control, and CI/CD integration.

What's New?

GA brings four substantive shifts to the customizable baselines experience: broader standards coverage, a faster path from customization to deployment, lifecycle management directly in the portal, and a new Overview page that surfaces compliance gaps at the subscription level. Together, these changes reflect what we heard from early customers during Preview: that custom baselines need to live alongside the rest of their governance workflows, not in a one-time wizard.

This cloud-native approach continues to embody Microsoft's Secure by Design and Secure by Default principles, with a sharper focus on the operational reality of running compliance at scale.

Built-in Policy Standards Coverage

GA expands what you can customize and where it's supported.

Standard	Status	Notes
CIS Benchmarks for Linux	Generally Available	Expanded distribution coverage since Public Preview. See the full list of supported distros in the official documentation.
[NEW!] CIS Benchmarks for Windows	Public Preview	Initial release covers L1 settings for WS2025 Domain Controller and Member Server roles.
Azure Compute Security Baseline for Windows	Generally Available	Now supports customization for Windows Server 2016 and 2019, in addition to 2022 and 2025.
Azure Compute Security Baseline for Linux	Generally Available	Aligned with Azure Compute recommendations across supported Linux distributions.

Key Scenarios

Faster Time to Deployment

The customization-to-assignment path is now a single continuous flow. You can:

Skip the JSON download step entirely. Baseline settings are auto-populated into the Azure Policy assignment flow, so you no longer have to download a JSON file, browse for it, and upload it back. The settings ride with you from Modify Settings straight into Assign Policy.
Use the improved settings editor. Role-specific values (Domain Controller, Member Server) and formatted inputs render cleanly in the UX, with validation that prevents malformed parameters from reaching the policy assignment.
Still export when you need to. The JSON download remains available for teams that want to commit baselines to source control, share with reviewers, or pipe through CI/CD.

The net result: what used to take a multi-step download-and-reupload sequence is now a few clicks inside one blade.

Lifecycle Management in the Portal

Compliance baselines are not write-once artifacts. They evolve as benchmarks update, as your controls tighten, and as your estate changes. GA introduces two capabilities that treat baselines as living configuration:

Import and Modify. From the Definitions tab under Machine Configuration, you can now import an existing baseline JSON and iterate on it directly in the portal. This closes the loop between policy-as-code workflows and ad-hoc edits, so you no longer have to choose between version-controlled artifacts and in-portal convenience.
Edit Settings on existing Assignments. The Assignments tab now supports updating an active baseline assignment in place. You can refine rules, adjust role-specific values, or exclude controls without tearing down and re-creating the assignment. All you have to do is select the policy assignment and the "Edit Settings" button should be enabled.

Together, these turn baselines into something you maintain, not something you set and forget.

New Overview Page: See Where You're Unprotected

A new Overview page on Policy > Machine Configuration gives you subscription-level visibility into where Machine Configuration is enabled and where it isn't. For each subscription it surfaces status (At Risk, Not Enabled, Enabled), machines missing prerequisites, machines with prerequisites in place, and total eligible machines. From the same view you can enable Machine Configuration on selected subscriptions to onboard eligible VMs and activate baseline auditing in a single action.

This shifts the first question from "is this one machine compliant?" to "which corners of my estate aren't even being assessed yet?", which is usually the more consequential gap.

Integration and Automation

Security baselines continue to integrate into your DevOps pipelines and configuration management workflows. Each baseline produces a declarative settings catalog (JSON) that can be versioned and deployed using Azure CLI, ARM templates, Bicep, and CI/CD automation, ensuring reproducible, traceable compliance configurations across environments.

Availability

Customizable security baselines are now generally available in all public Azure regions, Azure Government, and Sovereign Clouds.

Getting Started

Prerequisites

Before you begin:

Deploy the Azure Machine Configuration prerequisite policy initiative. (This installs the required Guest Configuration extension on supported VMs.) You can also do this in a single action from the new Overview page.
Ensure your Azure subscription or management group includes supported Windows or Linux VMs.
Have sufficient permissions (Owner or Resource Policy Contributor) to create and assign custom policy definitions.

Step-by-Step Guidance

Check your coverage on the Overview page to see which subscriptions are unprotected and onboard them with one click.
Select a baseline from the Definitions tab in Machine Configuration or use Import and Modify to iterate on an existing baseline JSON.
Modify settings to enable, exclude, or parameterize rules to match your internal policies.
Assign the policy directly from the wizard. Settings are auto populated into the assignment flow, no JSON upload required.
Iterate when needed. Use Edit Settings on the Assignments tab to refine active baselines in place.
Review compliance results to track outcomes in Azure Policy, Azure Resource Graph, or the Guest Assignments page.

Learn More

Please note that the use of Azure Machine Configuration on Azure Arc-enabled servers will incur a charge.

Introducing the Azure Resource Manager MCP Server!

stevenbucher — Mon, 11 May 2026 20:49:28 GMT

We're super excited to announce the public preview of the Azure Resource Manager MCP Server! This is a remote MCP server that provides tools to give AI agents first-class access to Azure infrastructure operations through Azure Resource Manager (ARM). AI agents can now be equipped with tools to generate, validate, execute Azure Resource Graph (ARG) queries and tools to deploy and manage ARM template deployments. This server is able to generate and execuite queries that return data across all your Azure resource types! At its core, this server is built to help AI agents interact with Azure resources seamlessly.

What this means for you

Ask natural language questions about your Azure estate to your agents and get real time, accurate answers backed with an ARG query
Deploy and manage infrastructure easily by having AI deploy ARM templates for you
Monitor deployment status and catch issues before they escalate
Ability to build more advanced AI agents that understand your Azure environment

What You Can Do Today

Generate, Validate, and Execute Azure Resource Graph Queries from Natural Language

No need to struggle with writing KQL from stratch! Describe what you need, and the MCP server tool generates Azure Resource Graph queries that match your intent. You ask an AI Agent: "Find all virtual machines in my subscription that don't have managed disks". It uses the tool and returns: A ready-to-execute ARG query without manual KQL writing. These queries spans across all your azure resource types so can learn and navigate across any type!

Deploy, monitor and cancel ARM Templates

Pass an ARM template, and the MCP server kicks off the deployment targeted to an existing resource group scope. Monitor the deployment by getting status about it and even cancel it if you decide its not doing what you need it to.

Here is the complete list of the tool available in this preview:

```
generate_query 
```
```
validate_query
```
```
execute_query 
```
```
create_template_deployment 
```
```
get_arm_template_deployment_status 
```
```
cancel_arm_template_deployment 
```

Real-World Scenarios

Infrastructure Compliance Audit

"Show me all resources created in the last 30 days that don't have required tags." - The MCP server generates and executes the query, returning resources that need remediation. Your team can then fix them programmatically or through Copilot.

Rapid Infrastructure Provisioning

"Using this ARM template <path to template>, deploy a secure storage account with HTTPS-only access, private endpoints, and Standard_LRS replication to my production resource group." This will take an existing ARM template and deploy it to a resource group scope.

You can ask your Copilot to generate the ARM template for you as well but there is no quality guarantee on the generated template so we recommend providing your own template for certainty in deployment.

Policy Compliance Check

"Check if all resources in my subscription comply with the latest policy applied to it." - The MCP server generates and executes the query, returning resources that are non-compliant. Your team can then take corrective actions programmatically or through Copilot.

Building Agents with Azure Resource Manager MCP Server

The MCP server's tools can be integrated into custom agents you build with GitHub Copilot. What this means is you can create custom agents that automatically check compliance, track changes in a scope, or ensure all resources have a particular tag applied to them!

Getting Started

Prerequisites

VS Code installed
Valid Azure account with appropriate permissions
GitHub Copilot subscription

Installation

Install the MCP Server

- Open https://aka.ms/JoinARMMCP
- VS Code launches automatically
- Click Install under Azure Resource Manager MCP Server
- Sign in with your Azure credentials
  - If you hit any authentication issues see Troubleshooting Guide in our repo

Check tools are enabled in Chat

- Open Chat in VS Code (View > Chat)
- Click Configure Tools
- Ensure the six Azure Resource Manager MCP Server tools are enabled

Start Using It

- Ask Copilot a question about your Azure resources or infrastructure needs
- The MCP server handles the rest

Governance & Security

The Azure Resource Manager MCP Server respects your Azure permissions and governance policies. All operations run in the context of your signed-in user. Additionally you can apply Azure Policies to prevent deployments via the MCP Server. Find more details in the README of our documentation repo.

What's Next?

We are actively expanding the capabilities of the Azure Resource Manager MCP Server! The Server will expand to include:

Additional ARM API capabilities with ARM
Enhanced query generation and optimization
Support for additional MCP clients beyond VS Code, next up: Claude

Get Feedback

We want to hear from you. Try the public preview and share your feedback. Found a bug? Or have a feature request? Open an issue on GitHub at https://aka.ms/ARMMCPIssue

Resources

- 📖 Full Documentation – Complete setup and usage guide

- 🔗 Install Now – Get started with the public preview

- 🐛 Report Issues – Share feedback and bugs

- ❓ FAQ – Common questions answered

- 🛠️ Troubleshooting – Resolve common issues

Try It Today

The Azure Resource Manager MCP Server public preview is available now. Visit https://aka.ms/JoinARMMCP to install and start automating your Azure infrastructure with AI.

What agents will you build with these tools? We can't wait to see how you'll use this.

Steven Bucher

PM on Azure Resource Manager and Azure Governance

New Local Management Group for ALZ & Updated Sovereign Policies for SLZ

jtracey93msft — Thu, 30 Apr 2026 07:58:07 GMT

Following on from months of working alongside customers, partners, and our internal product groups, we have now made two updates to the Azure landing zone (ALZ) and the Sovereign landing zone (SLZ), that I’d like to walk you through in this post:

A new dedicated ‘Local’ Management Group added beneath the Landing Zones Management Group – applies to both ALZ & SLZ
A refresh of the sovereign policy initiatives assigned in the SLZ, replacing the previous Sovereignty Baseline initiatives with new built-in initiatives that align directly to sovereign control levels 1, 2, and 3 – applies to SLZ only

A new ‘Local’ Management Group

What’s changing?

We have added a new dedicated ‘Local’ Management Group beneath the Landing Zones Management Group in the ALZ conceptual architecture, sitting alongside the existing Corp and Online Management Groups. And because the SLZ extends and takes a dependency on ALZ, this Management Group is inherited by the SLZ hierarchy too in the same hierarchy location, beneath the Landing Zones Management Group.

Azure landing zone conceptual architecture's Management Group hierarchy only. Download a Visio file or PDF file of this architecture.

Why have we added it?

We have been working closely with the Azure Local product group, customers, and partners on what good governance looks like for Azure Local within the ALZ architecture, and we kept hearing two consistent asks:

A clear, opinionated home in the Management Group hierarchy for Azure Local clusters and the workloads that sit on top of them.
A way to help customers — particularly those with sovereignty or resiliency requirements — design and run workloads in the Azure public cloud today that are ready to "exit" to Azure Local disconnected operations (ALDO) if they ever need to.

The new Local Management Group gives us a single, consistent scope to address both scenarios with the same governance and policy guardrails. It is therefore intended to be used both for:

Workloads running directly on Azure Local clusters — to apply consistent best practices, governance, and security guardrails for Azure Local deployments.
Workloads running in the Azure public cloud today that may one day need to be moved to run on Azure Local in disconnected operations mode — to make sure they are exit-ready by construction, rather than at the point you find out you need them to be.

How exit planning is supported

To make exit planning straightforward, the new ‘Local’ Management Group leverages the following new built-in Azure Policy:

[Preview]: Restrict resource types to Azure services supported in Azure Local disconnected operations — Definition ID dabf7c7f-5354-42de-a92a-8367f538dd71. Category: Azure Local, Version: 1.0.0-preview.

This policy can be used in a couple of ways depending on where a customer is on their journey:

In Audit mode, the policy gives you an at-a-glance view of which resource types currently deployed in subscriptions under the ‘Local’ Management Group are not available on Azure Local disconnected operations clusters. This is great for understanding the current state of an exit plan without changing developer behavior.
In Deny mode, the policy prevents deployment of any resource type that is not available on Azure Local disconnected operations clusters. Workloads can carry on running happily in Azure public, but they are exit-ready by construction — there is no scenario where someone "accidentally" introduces a service that breaks the exit story.

The important thing to call out here is that workloads do not have to run on Azure Local today to benefit from this. Customers with sovereignty or business continuity requirements that need a credible exit story to Azure Local disconnected operations can keep their workloads running in the Azure public cloud and use this new ‘Local’ Management Group, with the new built-in policy to Deny, to guarantee portability when they need it. The platform enforces it, rather than someone tracking it in a spreadsheet or other manual methods.

Further policies from the Azure local product group will be created and published in the future. These additional policies will focus on Azure Local cluster and workload best practices and other scenarios that can be assigned to the new ‘Local’ Management Group.

Do I place my Azure Arc-enabled resources in the new local management group?

This is a fantastic question and one that we have had a couple of times already since posting this blog post, hence updating it with this new section.

In short, no, we do not think that this is the best place to place your Azure Arc-enabled resources such as servers as a central location to group them all together. Instead, you should consider putting them with their existing resources in their own application landing zone subscriptions as per the normal Azure landing zone guidance, for example, in either a corp or online application landing zone governed subscription.

We actually wrote up this and other scenarios in the hybrid and multi-cloud cloud adoption framework scenario a few years back that we are sharing here for convenience, as we believe it will help many answer this question, if they have it. Please see Integrate Azure Arc resources with application landing zones for the guidance on this topic.

New sovereign policy built-in initiatives aligned to sovereign control levels 1, 2 & 3

What’s changing?

In the SLZ we have replaced the previous Sovereignty Baseline initiatives with a set of new built-in sovereign policy initiatives, assigned at the appropriate Management Group scopes in the Sovereign landing zone (SLZ), that align to the three sovereign control levels:

Level 1 — Data residency
Level 2 — Encryption-at-Rest / in-Transit
Level 3 — Encryption in use (Confidential Computing)

You can read more about each of these levels and the principles behind them on Microsoft Learn:

What was assigned before?

Up until this update, the SLZ assigned two existing Sovereignty Baseline built-in initiatives:

Sovereignty Baseline – Global Policies (c1cbff38-87c0-4b9f-9f70-035c7a3b5523) — 5 policies covering location restrictions and Trusted Launch.
Sovereignty Baseline – Confidential Policies (03de05a4-c324-4ccd-882f-a814ea8ab9ea) — 19 policies covering customer-managed keys, confidential compute, and resource type / location restrictions.

These were broad baselines, not purpose-built per sovereign control level. They did the job, but they didn’t map cleanly to the L1/L2/L3 model that customers, partners, and our own documentation use to talk about sovereign controls.

What’s assigned now?

Working with the Sovereign Public product group, we have moved the SLZ over to a set of new built-in initiatives that we have built and published recently, each aligned to a specific sovereign control level. These are now assigned by default in the SLZ in place of the two Sovereignty Baseline initiatives above:

Initiative	Control level	Purpose
[Preview]: Enforce Data Residency across Azure Services	Level 1 — Data Residency	Restrict / audit Azure regions; prevent cross-region replication (Cosmos DB, SQL, Storage, etc.)
[Preview]: Enforce Encryption-at-Rest with Customer Managed Keys (CMK) with Azure Key Vault Premium Keys across Azure Services	Level 2 — Encryption-at-Rest	Restrict / audit Azure services to use CMK with AKV Premium keys
[Preview]: Enforce Encryption-at-Rest with Customer Managed Keys (CMK) with Azure Key Vault Managed HSM Keys across Azure Services	Level 2 — Encryption-at-Rest	Restrict / audit Azure services to use CMK with AKV Managed HSM keys
[Preview]: Enforce Encryption-in-Transit across Azure Services - HTTPS	Level 2 — Encryption-at-Rest	Restrict / audit Azure services to use HTTPS/SSL
[Preview]: Enforce Encryption-in-Transit across Azure Services - TLS Version	Level 2 — Encryption-at-Rest	Restrict / audit Azure services to use latest TLS versions (e.g. TLS 1.3)
[Preview]: Enforce Encryption-in-Use across Azure Services	Level 3 — Encryption-in-Use	Restrict / audit to Azure Confidential Compute (ACC) VM SKUs or ACC-backed PaaS services

Sovereign landing zone conceptual architecture's Management Group hierarchy with the associated controls and principles applied. Download a Visio file or PDF file of this architecture.

Why have we done this?

Aligning the SLZ to these new built-in policy initiatives gives customers, partners, and our internal teams several benefits:

Single source of truth — the policies assigned by the SLZ now match exactly what is documented in the sovereign controls and principles guidance on Microsoft Learn. No translation, no mapping exercise.
Per-level alignment — each initiative aligns to a specific level (L1, L2, L3), so customers can map their data classifications (Public, Internal, Confidential, Secret) to the right scope in the hierarchy and apply only what is required for that classification.
Lower maintenance overhead — by moving from broad baselines to per-control built-ins owned by the Sovereign Public product group, customers benefit from updates made by the product group automatically, without us having to ship and version our own copies in the SLZ.
Easier auditing and reporting — built-in initiatives are first-class citizens in tools such as Microsoft Defender for Cloud and Azure Policy compliance reporting, which makes evidencing compliance against the sovereign controls easier for those that need to.

What if we have already deployed ALZ or the SLZ?

These changes are now live in the following releases in the Azure Landing Zones library.

We have also updated the ALZ Accelerator and our AVM-based Terraform & Bicep deployment options to use these latest releases for new deployments. And for those of you who already have an active deployment you can upgrade your library version following the guidance here:

The ALZ Portal accelerator is also being updated this week so stay tuned for those if you use that, although we highly recommend the ALZ IaC Accelerator.

Announcing One‑Command Backup Configuration for AKS with Azure Backup

shobhitgarg — Thu, 16 Apr 2026 07:50:59 GMT

Running production workloads on Azure Kubernetes Service (AKS) is becoming the norm for platform teams building cloud‑native applications at scale. As these environments increasingly host stateful workloads using persistent volumes, ensuring data protection and rapid recovery becomes mission‑critical.

Today, we’re excited to introduce an alternate simplified CLI‑based experience that allows customers to configure backups for AKS using Azure Backup with a single command.

The challenge with AKS backup onboarding today

Until now, enabling backup for an AKS cluster through Azure CLI required customers to understand and coordinate across multiple CLI domains, including:

az aks
az k8s-extension
az dataprotection

Configuring vaulted backup involved:

Extension installation
Storage account provisioning
Backup vault creation
Policy configuration
Trusted access setup
Backup instance initialization

All of which required orchestrating 8 separate lifecycle steps across 15+ CLI commands.

For platform teams managing tens or hundreds of AKS clusters through automation or CI/CD pipelines, this multi‑step setup often became a barrier to experimentation and adoption.

A simpler way: Configure backup in one CLI command

With this new experience, customers can now enable full‑cluster backup for AKS using a single CLI command:

az dataprotection enable-backup trigger \ --datasource-type AzureKubernetesService \ --datasource-id <cluster-arm-id> \ --backup-strategy <strategy> \ --backup-configuration-file @config.json

This command orchestrates the entire AKS backup enablement workflow behind the scenes by automatically performing the following steps:

Validate AKS cluster existence and running state
Create or identify region‑specific backup resource group
Check if Backup Extension is already installed on the cluster
Install Backup Extension (if not present)
Create or reuse Storage Account for backup data
Create or reuse Backup Vault
Create or reuse Backup Policy
Enable Trusted Access between vault and cluster
Initialize and create Backup Instance

Customers no longer need to manually orchestrate resources across different CLI surfaces.

Backup Strategy Presets

Customers can select predefined strategies aligned to common protection needs:

Strategy	Op Store Retention	Vault Store Retention	Use Case
Week (default)	7 days	—	Dev/Test
Month	30 days	—	Production
DisasterRecovery	7 days	90 days	Cross‑region DR
Custom	User-defined	User-defined	BYO Vault & Policy

Example:

az dataprotection enable-backup trigger \ --datasource-type AzureKubernetesService \ --datasource-id <cluster-arm-id> \ --backup-strategy DisasterRecovery

Backup Configuration JSON (Advanced Customization)

Advanced users can optionally provide a configuration JSON file to:

Use existing vaults or policies
Bring your own storage account
Apply enterprise tags
Use custom backup resource groups

Supported Parameters

Parameter	When Required	Description
backupVaultId	Custom strategy	Use existing vault
backupPolicyId	Custom strategy	Use existing policy
storageAccountResourceId	Optional	Use existing SA
blobContainerName	Optional	Custom container
backupResourceGroupId	Optional	Use existing RG
tags	Optional	Apply to created resources

Built‑in validations for reliability

Before enabling backup, the CLI automatically validates:

Cluster existence
Running state
Backup compatibility
Required RBAC permissions
Resource availability (if provided)

Faster time‑to‑protection for AKS workloads

By collapsing a previously multi‑step setup into a single command:

Backup onboarding becomes automation‑friendly
Platform teams can enable protection consistently across environments
Setup errors from manual orchestration are reduced
Backup rollout across large AKS estates becomes significantly faster

What’s next

The simplified single‑command backup enablement experience introduced for AKS is part of a broader effort to make Azure Backup more automation‑friendly across cloud‑native and platform workloads.

We are actively working to extend this model to other workloads supported by Azure Backup, enabling customers to:

Configure protection using native CLI workflows
Reduce onboarding complexity across backup‑supported resources
Integrate backup enablement seamlessly into CI/CD pipelines
Achieve faster time‑to‑protection across heterogeneous environments

Over time, customers can expect similar single‑command backup configuration experiences for additional Azure Backup‑supported workloads — bringing consistency and ease of adoption across their backup strategy.

For more information, see how to configure AKS backup using a single CLI command.

Announcing Public Preview for Essential Machine Management

Meagan McCrory — Mon, 06 Apr 2026 18:54:19 GMT

Managing servers and VMs across Azure, on premises, and multi-cloud environments often means turning on core capabilities—monitoring, updates, inventory, and configuration—through separate setup experiences. We’ve heard feedback that this makes it harder to get visibility into machine state and take actions.

We’re excited to announce the public preview of Essential Machine Management experience within Compute Infrastructure Hub—a new entry point in Azure that streamlines onboarding for machines at scale and enables basic management capabilities. Start once at subscription scope, get a clear view of what’s turned on, and move from setup to operations faster across your Azure and cloud and hybrid estate.

What is Essential Machine Management?

Essential Machine Management is a centralized onboarding experience that helps customers enroll their machines into a set of selected cloud-native management services from Azure in a simple, scalable way,

Instead of enabling monitoring, updates, inventory, and configuration independently per machine, Essential Machine Management allows you to enroll entire subscriptions at once, including both Azure Virtual Machines and Azure Arc–enabled servers. These services are pre-configured with best practices, enabling customers with out-of-the-box value right away.

Once enrolled, current and future machines in the selected subscriptions are automatically onboarded to the enabled management services, helping ensure consistent visibility and operational coverage from day one.

What management capabilities are enabled?

Using Essential Machine Management, you can quickly onboard machines to multiple Azure management capabilities, including:

Monitoring insights and recommended alerts for machine health and performance
Azure Update Manager to help keep machines secure and compliant
Change tracking and inventory for visibility and auditability
Machine configuration for managing in-machine configuration, compliance and security
Azure Security baseline policy is a set of tailored rules to assess your machine's security posture

These services help keep your infrastructure secure and healthy.

How much does it cost?

Azure VMs: For Azure Virtual Machines only, capabilities enabled by Essential Machine Management are provided at no additional charge.

Azure Arc-enabled servers:

For Azure Arc-enabled servers with Windows Server Software Assurance, Windows Server PayGo, and Windows Server Extended Security Updates, capabilities enabled by Essential Machine Management are provided at no additional charge.
For all other Arc-enabled servers, Essential Machine Management will be priced at $9 per server per month once billing is enabled. See more details here.

Getting started

If you manage Azure VMs or Arc-enabled servers and are looking to simplify how you onboard and manage machines at scale, Essential Machine Management feature is now available for you to try in public preview. Check out the preview in the Azure Portal under Compute infrastructure --> Monitoring + Operations --> Essential Machine Management (preview):

Check out Essential Machine Management now and reach out to machineenrollmentsupport@microsoft.com for any feedback or support. Learn more about Essential Machine Management here.

Azure Policy: Required Actions for Docker Content Trust Deprecation in Azure Container Registry

ShannonHicks — Wed, 17 Dec 2025 22:36:46 GMT

As Azure evolves, certain features are deprecated to streamline services and improve security and performance. One such upcoming change is the deprecation of the Docker Content Trust (DCT) feature in Azure Container Registry (ACR) which is ongoing over a three-year period. This change will eventually remove the trustPolicy property from underling APIs.

This blog post explains what is changing, the potential impact on your Azure Policy environment, and steps you can take to mitigate disruption.

What is Changing?

The Docker Content Trust (DCT) feature in ACR is being deprecated. As part of this process:
- The trustPolicy property will be removed from ARM APIs in a future version.
- The Azure Policy aliases referencing this property will eventually be impacted.
Affected aliases include:
- Microsoft.ContainerRegistry/registries/trustPolicy
- Microsoft.ContainerRegistry/registries/trustPolicy.type
- Microsoft.ContainerRegistry/registries/trustPolicy.status
Key findings:
- No built-in policy definitions currently use these aliases, so no built-ins will be deprecated because of this feature deprecation.
- The alias trustPolicy.status is modifiable, so any active modify policies targeting this property will break when the property is removed. This alias will be removed.

Impacts on Azure Policy

If you have active policy assignments referencing these aliases, you will need to update or remove them during the deprecation period to avoid future compliance issues:

Existing policies will eventually become non-compliant for any new ACR resources. For example, if a policy assignment requires trustPolicy to be enabled (Microsoft.ContainerRegistry/registries/trustPolicy.status == "enabled"), but the ACR trustPolicy property can no longer be set due to deprecation, then any new ACRs created after that point will automatically be noncompliant with the policy.
Policies using the modifiable alias (trustPolicy.status) will fail when the alias is deleted or marked non-modifiable at the end of the deprecation period.

Steps to Mitigate the Impact

To ensure a smooth transition:

Identify Affected Policies and Assignments: Locate any custom policy definitions in your environment referencing the affected aliases.
Update Policy Definitions: Remove or replace references to trustPolicy properties in your policy definitions. If the policy's only purpose is to evaluate the ACR trustPolicy, consider removing the definition altogether.
Test and Validate: After updating policies, validate that they enforce compliance as intended without relying on deprecated properties.
Monitor for Updates: Stay informed by monitoring Azure Container Registry retirement documentation for more details on transitioning from Docker Content Trust to Notary Project.

Announcing General Availability for Azure Resource Graph (ARG) GET/LIST API

JaspreetKaur — Wed, 03 Dec 2025 04:39:28 GMT

ARG GET/LIST API delivers 10X higher throttling quotas to callers compared to ARG query unlocking a more scalable, resilient way to perform resource lookups in Azure. ARG GET/LIST API is a new platform capability within Azure Resource Graph that provides a high-performance experience for both Point GET and collection GET requests. A key advantage of this capability is its ability to significantly reduce READ throttling for high volume calls efficiently. This is made possible through intelligent control plane routing based on a query parameter controlled by the caller. When a specific query parameter is included, requests are automatically directed to this optimized ARG GET/LIST backend. When the parameter is omitted, requests flow to the Resource provider —ensuring flexibility and backward compatibility.

What Challenge Are We Addressing?

Azure Read Throttling is a significant challenge for many customers. When services hit throttling limits, applications may experience performance degradation, elevated latency, or even failed requests—issues that can disrupt critical workloads and customer operations.

The ARG GET/LIST API is designed to directly address this problem. By routing GET and LIST calls through Azure Resource Graph’s scalable indexing infrastructure and intelligent control-plane routing, it dramatically reduces the likelihood of read throttling. Best of all, it follows the ARM control plane GET APIs request response contract, allowing you to benefit from improved performance and reliability with minimal effort, appending the flag “useResourceGraph=true”.

When to use Azure Resource Graph (ARG) GET/LIST API

The ARG GET/LIST API is designed for scenarios where you need to retrieve a single resource by its ID or list resources of the same type within a defined scope—whether that's a subscription, resource group, or parent resource.

You should consider using the ARG GET/LIST API if your service fits into one or more of the following categories:

High Volume of GET Calls Within a Single Scope:
Your service issues a large number of GET requests targeting resources within a single subscription or resource group, without the need for cross-subscription queries, complex filters, or joins.
Risk of Throttling or Quota Competition:
Your service produces a high volume of requests and may encounter issues such as::
- Experience throttling during sudden traffic spikes.
- Quota competition, where other workloads in the same subscription consume shared quota limits, causing your service to be throttled.
- Bursty traffic patterns, where large volume of GET requests are issued within a short time window, increasing the chance of throttling.
Need for High Availability and Faster Performance:
Your service depends on consistent; low-latency GET operations for either single-resource lookups or listing resources within a specific scope

Note: The ARG GET/LIST API is currently supported only for resources in the resources and computeresources tables.

Using the ARG GET/LIST API

To get started with the ARG GET/LIST API, begin by assessing whether your scenario aligns with the recommended calling patterns and throttling considerations described earlier. Once confirmed, simply append the parameter &useResourceGraph=true to your eligible GET/LIST API calls. This flag routes your request through the Azure Resource Graph GET/LIST API backend, allowing you to take advantage of its optimized performance and query efficiency. No calls will route to ARG GET/LIST backend automatically. The switch is entirely in the user’s control—the call will route to ARG GET/LIST API only when you explicitly include the useResourceGraph=true parameter in your request.

Follow the ARG GET/LIST API contract here - Azure Resource Graph GET/LIST API Guidance - Azure Resource Graph | Microsoft Learn

Let’s walk through a simple example of retrieving a Virtual Machine (VM) along with its InstanceView through ARG Query vs. ARM API vs. ARG GET/LIST API to show the difference in the calling experience.

Using an ARG Query (via ARG Explorer)

In ARG Explorer, you can use Kusto Query Language (KQL) to query resources.
A sample query to retrieve a specific VM looks like this:

Resources | where type =~ 'microsoft.compute/virtualmachines' | where id =~ '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}'

This query filters the Resource Graph index to return the VM resource.

Using the ARM (Compute RP) API

The equivalent ARM API call to retrieve the VM with InstanceView is:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView

This hits the Compute Resource Provider, pulls the VM state, and expands the instanceView section.

Using the ARG GET/LIST API

ARG GET/LIST APIs that follow the same request structure as ARM—but with an additional flag that routes the call through ARG:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView&useResourceGraph=true

The important distinction here is the useResourceGraph=true parameter, which routes the call through ARM to serve the response through ARG’s GET/LIST backend.

Sample Response -

You can find more examples in our documentation - Azure Resource Graph GET/LIST API Guidance - Azure Resource Graph | Microsoft Learn

Video Walkthrough

Increase Throttling Quota via Azure Resource Graph

Learn More

Azure Resource Graph GET/LIST API Overview

Known Limitations

Frequently Asked Questions

Share Your Feedback

For questions and feedback, you can reach us at Azure Resource Graph team 
Share Product feedback and ideas with us at Azure Governance · Community

Happy Querying!

Azure Governance @ Ignite 2025

jodiboone — Sat, 22 Nov 2025 01:24:16 GMT

Recap: Azure Governance @ Ignite 2025

Azure governance is thrilled to be back at ignite this year with some exciting updates. In this blog we will be sharing highlights from the session, overviews on new releases, and links on how you can get started using governance products including Azure Policy & Service Groups to maintain a well governed environment where you can deploy secure applications. Make sure to catch the recording if you missed it to see how Microsoft deploys these products in practice!

Service Groups

Service groups is the newest product in the Azure governance suite allowing you to maintain more dynamic and flexible resource hierarchies. To recap, service groups provide:

Low Privilege Management: Service Groups are designed to operate with minimal permissions, ensuring that users can manage resources without needing excessive access and appealing to multiple personas. Access to a Service Group does not grant role-based access control or policy inheritance to its members.
Flexible and Varying Hierarchies: Azure resources and scopes, from anywhere in the tenant, can become members of one or multiple service groups. Additionally, Service Groups can be nested providing the ability to have multiple hierarchy structures, i.e. Cost Center, Product, Organization, and more!

Service groups has recently gone Public Preview and this year at ignite we are excited to announce new integrations including,

Azure Monitoring

Azure Resiliency

Stay tuned for future integrations and get started using service groups today at: aka.ms//servicegroups

Azure Policy

This ignite we are excited to showcase new releases enriching the power of the policy language and improving ease of use through major UX improvements.

To start off, we announced our public preview for Identity Based Exemptions, a new type of exemption resource that targets the callers service principal versus the scope on which the exemption is applied. Allowing admins to place targeted exemptions for approved service principals, to avoid over exempting without interrupting business critical workflows.

New Home Page Experience!

As the policy framework has expanded, the focus of your policy management has expanded beyond just compliance, to other aspects of the policy deployment lifecycle, including exemptions & remediations. We also know that one size does not fit all, so we are excited to release a new Azure policy UX landing page that provides a refreshed view on compliance, policy status, and will showcase how to get started using new primitives & releases. Try it out and let us know what you think!

Machine Configuration Customizable Baselines

The Azure Windows and Azure Linux baselines have provided a standard set of guidance for how to configure server operating systems in Azure. To make these baselines more relevant to changing regulatory standards & business goals, we’re

releasing an extensibility framework to make it easier than ever to deploy custom Azure baselines through Azure policy & Machine configuration.
Aligning the baseline content to be aligned with CIS across our supported distributions

Getting started is easy, select the baseline that you’re interested in applying and adjust any settings based on business requirements.

For more details on getting started visit: aka.ms//machinebaselines

Optimize Your Cloud Environment Using Agentic AI

riteshkini — Tue, 18 Nov 2025 16:20:32 GMT

In today’s cloud-first world, optimization is no longer a luxury—it’s a strategic imperative. As IT professionals and developers navigate increasingly complex environments, the need to reduce costs, improve sustainability, and accelerate decision-making has never been more urgent.

At Ignite 2025, Microsoft is introducing a new wave of agentic capabilities within Azure Copilot—one of the key capabilities includes the optimization agent, designed to help you identify, validate, and act on opportunities to streamline cloud operations. For FinOps teams, this agent becomes especially powerful, enabling cost governance, carbon insights, and actionable recommendations to maximize financial efficiency at scale.

From Complexity to Clarity

For users familiar with Azure’s cost and performance tools, the new operations center experience in the Azure Portal provides a unified agentic experience to monitor spend and carbon emissions side by side, surface the most critical optimization opportunities, and seamlessly trigger actions by invoking the Optimization agent—bringing governance, efficiency, and sustainability into one streamlined experience.

What’s New in Optimization

The optimization agent in Azure Copilot empowers teams to:

Identify top actions prioritized by impact, cost savings, and ease of implementation.
Evaluate cost and carbon impacts side-by-side, helping you make informed decisions that align with financial and sustainability goals.
Validate recommendations with supporting evidence, current / projected utilization trends, and alternative SKU choices.
Accelerate implementation with step-by-step guidance and agentic workflows that reduce toil and increase confidence.

These capabilities are designed to scale FinOps impact, enabling collaboration across engineering, finance, procurement, and sustainability teams—all within a unified experience.

A Day in the Life: FinOps in Action

Let’s step into the shoes of a FinOps practitioner at a large enterprise navigating the complexities of cost management.

It’s Monday morning. Over the weekend, a set of development VMs were left running, quietly accumulating costs. The optimization agent—a capability within Azure Copilot—surfaces a top action: resize or shut down the idle resources. With a few clicks, the practitioner reviews the supporting evidence, including usage trends, cost impact, and carbon footprint. The agent offers visibility over alternative SKUs and guides the practitioner through a step-by-step implementation—all within the same interface.

But it doesn’t stop there. For teams that prefer automation or scripting, the agent also generates Azure CLI and PowerShell scripts tailored to the recommended action. This gives practitioners flexibility: they can execute changes directly in the portal or integrate scripts into their existing workflows for repeatability and scale. The experience is seamless—every recommendation is actionable, verifiable, and aligned with enterprise policy.

By midweek, the practitioner has implemented multiple optimizations without leaving the console or writing custom code. Each action is logged for audit visibility, ensuring compliance and transparency across the organization. What used to take hours of manual investigation and coordination now happens in minutes, freeing the team to focus on strategic initiatives rather than firefighting cost overruns.

Why It Matters

These aren’t just features—they’re answers to the pain points customers have been voicing for years.

Cost visibility and predictability: Azure Copilot centralizes insights across subscriptions, helping teams avoid surprise bills and understand where every dollar goes.
Resource inefficiencies: The optimization agent proactively identifies underutilized resources and guide teams to act before costs escalate.
Scalability and complexity: Azure Copilot’s unified experience simplifies operations for even the most complex setups.

Azure Copilot isn’t just simplifying cloud operations—it’s transforming how teams collaborate, govern, and optimize.

Get Started at Ignite

At Ignite 2025, you’ll get hands-on with Azure Copilot’s optimization capabilities. Explore how intelligent assistance can help you:

Reduce cloud costs
Improve sustainability metrics
Strengthen governance and compliance
Drive better outcomes—faster

Azure Copilot: turning cloud operations into intelligent collaboration. Sign up for the Agents in Azure Copilot Limited (Preview) and try the experience today.

Improve your resiliency posture with new capabilities and intelligent assistance

rochakm — Tue, 18 Nov 2025 16:36:10 GMT

In today’s cloud-first world, resilience isn’t optional—it’s mission-critical. The next phase of cloud operations is about simplifying workflows, enhancing control, and removing friction from daily work. At Microsoft Ignite 2025, Azure is redefining resiliency with expanded capabilities to include Infrastructure Resiliency, Data Resiliency, and Cyber Recovery with AI-powered innovations designed to help you maintain uninterrupted business continuity.

Introducing the resiliency agent in Azure Copilot

With natural language guidance and automated actions, we are announcing the preview of the resiliency agent in Azure Copilot which helps you assess your current posture, fix gaps with intelligent automation, and continuously monitor your environment to keep critical workloads safe from disruptions.

Infra Resiliency: Leverage Guided Experiences to Become Zonally Resilient

The new Infrastructure resiliency experiences are designed to keep your critical applications running—even during unexpected zonal outages. These new capabilities empower you to actively assess and improve your architecture and continuously validate your resiliency posture.

Leverage at-scale views across Resources and Service Groups to uncover resiliency blind spots and prioritize remediation. Set resilience targets for your key workloads and invoke the resiliency agent from the operations center in Azure to proactively find resources (like virtual networks or firewalls) that are deployed in only one availability zone and could become single points of failure. Once identified the agent will highlight which resources aren’t zone-resilient and the risks they pose, such as potential downtime or IP address changes during a zone failure, enabling you to prioritize the most crucial gaps first. Then with a click, the agent will generate ready-to-run scripts (or commands) to distribute those resources across zones to address configuration drift and strengthen architecture. This guided automation ensures that even if an entire Azure zone goes down, your application stays up.

You can then validate readiness with built-in failure scenario drill templates (e.g., simulating a full availability zone outage) and proactively test failover behaviors without impacting production using default faults or custom runbooks. Create predefined recovery plans that sequence the failover of your application’s components during test drills or actual failovers and execute them with a single click to automatically fail over workloads to another Availability Zone. Track failover progress in real time, monitor key performance metrics, and export attestation reports for compliance and audit readiness.

By streamlining what used to require multiple tools and significant expertise, you can utilize proactive insights, automated recovery, and continuous validation, to confidently strengthen your architecture, maintain operational continuity, and achieve high availability by design without the usual complexity.

Beyond Infrastructure: Data and Cyber Recovery

The expanded resiliency experiences go beyond infrastructure, bringing in powerful new & existing capabilities that help you stay protected and recover fast, whether it's meeting your RPO and RTO goals through smarter data protection or defending against ransomware with built-in cyber-recovery. At Ignite, we’re excited to showcase new innovations designed to help you strengthen your business continuity strategy and stay ahead of evolving threats.

Data Resiliency: Fortify your Cloud Data with enhanced workload protection & disaster recovery

Never get caught without a backup plan. Azure Backup is evolving toward application-centric recovery, expanding coverage to protect critical cloud-native workloads that power enterprise data apps. As part of this journey, we’re introducing vaulted backups for ADLS Gen2—a native, secure, and managed solution that safeguards data against deletion, corruption, and malicious threats. Additionally, agentless backup for Windows and Linux VMs is now available, offering crash-consistent protection across multiple disks with high-frequency, lightweight backups. This makes it ideal for performance-sensitive workloads such as databases, delivering reliable protection with minimal operational overhead.

And rather than manually checking each service or using separate dashboards for backups and disaster recovery, you can ask the resiliency agent to summarize your backup coverage across both primary and secondary regions. It will report which virtual machines, databases, or other resources are already backed up and replicating, and which ones might need attention. With granular recovery, long-term retention for compliance, and enterprise-grade management through the Resiliency blade in Azure, you can confidently ensure business continuity across your most vital workloads.

As part of our continued investment in resilience and scale, Azure Site Recovery now offers a suite of powerful enhancements to support enterprise-grade disaster recovery. Capacity Guidance now provides alternative VM size recommendations during failovers to improve allocation success in target regions. ASR now supports up to 5x churn (500 MB/s per VM), enabling protection of high IOPS workloads and ensuring robust recovery for data-intensive applications. We’ve also expanded disk support with Premium SSD v2 and Ultra Disks now fully supported, allowing seamless protection of performance-critical workloads across Azure regions. Finally, ASR enables failback from Azure VMs to on-premises Hyper-V even when the original replication used a storage account and the failed-over VM was converted to managed disks, offering greater flexibility and control in hybrid recovery scenarios.

For any critical resource that needs failover and failback capabilities, the agent can recommend the next step, like enabling Azure Site Recovery for cross-region replication. By turning on Site Recovery (with the agent’s guidance), you add a second layer of protection: if your primary region suffers an outage, those critical VMs can fail over to a secondary region with minimal downtime. In short, the resiliency agent ensures your data meets your business continuity goals. It helps you balance recovery point objectives (keeping data loss to a minimum with frequent backups) and recovery time objectives (restoring services quickly via failover). Through Copilot’s conversational interface, you can instantly get answers like “Are all my tier-1 workloads protected in a secondary region?” and follow prompts to fill any gaps reducing the need to hunt through multiple tools. The result is a cloud estate that’s not only backed up, but truly disaster-ready.

Cyber Recovery: Safeguard your critical data against Ransomware Attacks

Fortify your backups against cyber threats. Strengthen your organization’s cyber recovery with Azure Backup’s Vault Soft Delete. This feature is enabled by default across all Recovery Services Vaults and ensures that backups remain recoverable for at least 14 days, even in the event of accidental or malicious deletions. It applies comprehensively to vaults, containers, backup items, and recovery points, offering robust protection against ransomware threats.

The resiliency agent in Azure helps guard your backup data and recovery systems so they remain reliable even if attackers strike. It continuously reviews the security posture of your Recovery Services Vaults (where your backups are stored) and other protection settings. If it finds that any backup vault is missing critical safeguards—say, if soft-delete or immutability isn’t enabled—it will alert you and recommend enabling them. Through the Copilot interface, you can simply ask something like “How secure are my backups?” and the agent may respond with a summary like: “4 of 5 backup vaults have soft-delete and immutability on. One vault needs immutability; enable it now?” You can then approve the suggestion, and the agent will automatically apply the setting or provide a script to do so. Through intelligent guidance and recommendations, the resiliency agent ensures your backups are tamper-proof and ready to restore. Therefore, even if a ransomware attack or accidental deletion hits your environment, you’ll have clean, safe backups to recover from. In essence, the agent helps make sure that when trouble comes, your last line of defense, your backup, remains intact and readily available.

Additionally, Azure Backup now also integrates with Microsoft Defender for Cloud (MDC) to enhance the security of Azure VM backups. With a one-time setup via Defender for Servers, Azure Backup automatically assesses the health of recovery points at the time of snapshot creation using Defender signals. This marks a significant step toward proactive threat detection in backups, helping organizations strengthen their overall cyber resilience posture.

Together, data resiliency and cyber recovery form a unified defense strategy that ensures enterprise-grade protection across the full spectrum of threats—from accidental data loss to sophisticated ransomware attacks. By combining deep workload-aware backup and disaster recovery with proactive threat detection and secure retention, Azure empowers organizations to safeguard critical data assets and recover swiftly with confidence. This integrated approach not only meets business continuity goals but also strengthens security posture, delivering resilient-by-default coverage for modern cloud environments.

Next Steps

Azure is reaffirming its commitment to enterprise resilience. Whether it’s a datacenter outage, a cyberattack, or a zonal disaster, your applications and data can keep running and recover swiftly.

Join us at Ignite 2025:

Connect with Microsoft experts at the Azure Copilot, Operations, and Management expert meet-up booth to get your questions answered.

Additional Resources:

Learn more about specialized agents across the entire cloud management lifecycle: Introducing Azure Copilot
Sign up for the preview of Azure Copilot here
Read about best practices about how to start, get, and stay resilient here
Explore Resiliency features in Azure and join us in this journey from reactive recovery to proactive resilience here
Explore new Learn documentation here