deny status is set to inapplicable

[maikvandergaag]

Describe the bug When deploying a bicep file that deploys to two subscriptions. The resources deployed to one subscription get the correct deny status but in the other subscription the get inapplicable. Looking at the documentation this means that the resources are not within the scope. But the subscription is also under the management group.

To Reproduce Steps to reproduce the behavior:

1. Use the below bicep file: `param name string param location string = deployment().location param resourcesSubscription string param monitoringSubscription string

module monitoringGroup 'rg.bicep' ={ name: 'deploy-monitoringGroup' params:{ name: name prefix: 'mct' location: location } scope: subscription(monitoringSubscription) }

module applicationGroup 'rg.bicep' ={ name: 'deploy-applicationGroup' params:{ name: name prefix: 'mvp' location: location } scope: subscription(resourcesSubscription) }

module appInsights 'br/gaag:applicationinsights:0.0.1' = { name: 'deploy-appInsights' params: { environment: 'dev' logAnalyticsWorkspaceId: loganalytics.outputs.workspaceId name: name } dependsOn: [applicationGroup] scope: resourceGroup(resourcesSubscription, 'mvp-rg-${name}') }

module loganalytics 'br/gaag:loganalytics:0.0.1' = { name: 'deploy-loganalytics' params: { environment: 'dev' name: name } dependsOn: [monitoringGroup] scope: resourceGroup(monitoringSubscription, 'mct-rg-${name}') }`

Some modules must be replaced by local modules

2. Deploy the stack az stack mg create --name 'stack-demo-04' --management-group-id 'Personal' --template-file '.\demo-04\main.bicep' --parameters '.\demo-04\main-param.bicepparam' --location 'westeurope' --deny-settings-mode 'denyWriteAndDelete' --deny-settings-apply-to-child-scopes --deny-settings-excluded-actions 'Microsoft.Resources/tags/*'`
3. Check the status in the portal, and see the deny status

Expected behavior The Deny Status is 'denyWriteAndDelete' for all resources

[dantedallag]

HI @maikvandergaag, could you provide our team with the modules you are using? You can email them to ARMDeploymentStacks@microsoft.com.

Also, is this the sub that is not working directly under the MG you are deploying at or is it under a nested MG? Would be great to understand a bit about the structure here.

[maikvandergaag]

HI,

This is the structure:

The deployment is done to the Personal MG and the subscriptions that I was using are the MCT en MVP one.

The module files can be found on GitHub: https://github.com/maikvandergaag/msft-bicep/tree/main/modules if you want me to send them directly that is also fine.

[dantedallag]

@maikvandergaag Great, thanks! I will start looking into this. Do you also have a correlation id for the last time you ran into this?

[azcloudfarmer]

Hello @maikvandergaag - friendly ping on the correlationID. Also, can you share what version of CLI you are using for this deployment stacks?

[maikvandergaag]

Sorry totally missed that message. Do not have a correlation id but i did run it again today with the same result

[dantedallag]

@maikvandergaag Just double checking if you were able to run this again and get a correlation id. Thanks!

[azcloudfarmer]

@maikvandergaag friendly reminder on correlationID for this issue. Thanks!

[azcloudfarmer]

Hello @maikvandergaag - friendly ping on this thread

[maikvandergaag]

@dantedallag: sorry for some reason I did not get notified. This is the correlation ID of the deployment: 30572bb7-8401-4ecc-a6b7-483f558c808f.

Or do you need another one?

[snarkywolverine]

@maikvandergaag Thanks for that! I took a look and have identified what is happening. If my understanding is correct, I think this scenario can only be achieved by two deployment stacks.

The CLI command you are using is targeting the default subscription for the deployment, rather than the current management group. This was a bug in our initial release of CLI commands for public preview, but has since been changed to target the management group instead.

However, if you run the same command in the newer version of CLI, you will get an error, because we do not currently support deploying deny assignments for stacks at management group scope - see #137 for details.

If you were intending for the stack template to be deployed to the subscription (starting with a61), then the behavior here is correct -- the other subscription is "out of scope" and deny assignments are not applied.

I hope that all makes sense!

If the goal really is to have resources protected with deny assignments in two separate subscriptions... the best way to do that right now is to have separate stacks.

[azcloudfarmer]

Hi @maikvandergaag - closing this issue for now. Please feel free to reopen if there are any more questions.