Performing Policy Scope while following Azure Managment Group best practices

[mrwalters1988]

All,
I'm curious how to apply policies using a Dev/Test/Prod environment scope when following the Azure CAF recommended architecture of explicitly NOT defining a management group for landing zone sub-environments. Specifically, documented here:

Don't create management groups for production, testing, and development environments. If necessary, separate these groups into different subscriptions in the same management group.

The best way that I've currently thought of is to make use of notscopes and wildcards to exclude subscriptions matching a nonprod naming convention, however the scope requires a subscriptionID, not a subscription name, so I'm at a loss for how this would be implemented.

[stateofthearb]

In my experience

/subscriptions/$subName doesn't work

/subscriptions/$subID does work
/subscriptions/subId/resourceGroups/$rgName does work
/subscriptions/*/resourceGroups/$rgName does work
/subscriptions/subscriptionsPattern/$subName does work.

dev/test
/subscriptions/subscriptionsPattern/sub-tst*
/subscriptions//resourceGroups/rg-uks-tst

[krallsm]

for testing policies specifically, you'll want to create separate management groups which is contradictory to the general guidance, kind of. Anything that's not policy testing, I would follow the recommended general guidance, but it's hard/impossible to actually test policies without copying your prod environment to dev/test, which would be the management groups for policies.

Us personally, we've got a separate tenant we use for testing, however it could be just as easily done with a separate intermediate root management group. Once done testing, clean up the resources, you don't HAVE to clean them up, but that's good practice.

The missing whatif functionality hurts the ability to do this fully properly, but the fix should hopefully be pushed out next month as they roll out the changes starting on 6/30.