Bug Report - Enable DDoS Std policy does not work with managed VNets
Describe the bug Certain PaaS services - we tested Databricks and AKS - manage underlying network in a specific way. In my customer environment, we have the following policy enabled (comes as part of Contoso reference implementation):
- Policy name: Virtual networks should be protected by Azure DDoS Protection Standard
- Policy definition ID:
/providers/Microsoft.Authorization/policyDefinitions/94de2ad3-e0c1-4caf-ad78-5d47bbc83d3d
This is a 'Modify' policy, but it doesn't work for PaaS services mentioned above. Their VNets are then listed as non-compliant and there seems to be no way to fix it.
Steps to reproduce
- Deploy Azure Databricks service in your subscription, where this policy has been assigned (in the RI, it is assigned on
{prefix}-landingzonesMG). - Check the compliance in the Azure Policy - Compliance blade.
Screenshots

Thanks for raising awareness of this @pazdedav.
Do you get any error messages when trying to remediate the policy or enable DDoS on the VNET manually? (share any correlation IDs 👍)
Update
The same issue (with managed VNets) is valid for Deploy a flow log resource with target network security group policy as well, this time it is about the inability to modify Network Security Groups.
Thanks for raising awareness of this @pazdedav.
Do you get any error messages when trying to remediate the policy or enable DDoS on the VNET manually? (share any correlation IDs 👍)
I will try to reproduce the error while remediating the policy or updating the VNet config manually, @jtracey93 👍
Any updates @pazdedav?
We were able to test on a databricks VNET and it worked

I got write access to the environment, so I could reproduce the error and provide more input / info, @jtracey93 . I will update this issue with more details 👍.
Hello @jtracey93 I was able to reproduce the error (about a "deny assignment") when trying to remediate that non-compliant VNet:

It is important to note, we are testing a scenario with Databricks-provided VNet and not "Bring Your Own VNet", where I assume our customers have more control over the VNet and its settings.
I am getting the same result (error) when trying to change the configuration manually.
Thanks @pazdedav, this actually looks like its because its a locked VNET rather than a policy issue. Have you raised or the customer raised a support ticket to ask if possible? Could be a good idea
Thanks for your input, Jack.
Yes, the VNet is locked, and I believe this is expected behavior. This VNet is managed by Azure Databricks service, so nobody should fiddle with it and apply a configuration that might affect its behavior. We could raise a support ticket, but I expect that CSS would say: "This VNet needs protection from configuration changes, it is required by the RP".
My point is that this ALZ policy does not work with 'managed VNets', so it will always be shown as incompliant. The question is what guidance should be provided for our customers:
- should they create Exemptions on case-by-case basis to avoid "reds" in the Compliance report?
- should the policy definition be modified to exclude VNets that are managed by services like Databricks, Synapse, etc.?
And even if we pick one or the other, how does this affect customers' ability to apply DDoS protection for those managed VNets?
No worries and thanks for yours to @pazdedav,
I think for now whilst we work on if this could be supported on managed VNETs with engineering we would advise to create an exemption for the resources or scopes, as required so the compliance report is reflected correctly.
Thanks for the guidance @jtracey93. Much appreciated.
Trigger ADO Sync 1
Trigger ADO Sync 2