Closed jmutchek-msft closed 3 months ago
Thank you for your detailed feedback. We are looking into the issue, and we will respond when we have more information.
Thank you for your feedback. This has been assigned to the content owner, @rthorn17 , and will be updated as appropriate.
Hi @jmutchek-msft - Thank you for bringing this up to my attention. I will need to see how we can update this page as this is a valid scenario, while also supporting the different Landing Zone Scenario that the CAF is discussing. There are a few differences between the scenarios that are not called out clearly. The CAF is saying that having a single parent MG for the Application, then having three separate environment MGs as children is not scalable, which is correct. The example on this page is showing if you have one production environment MG with all your application production subscriptions under it. This results in a single MG with restricted accesses for Prod deployments on all Prod Subs, while separating those other environments out for different policies.
I will reach out to the teams that work on the CAF and see how we can align better. Thanks
Thank you for the documentation feedback. I created an internal backlog work item to review the issue. I'm closing the GitHub issue.
The example management group structure in the docs diagram depicts a "production" management group, while the CAF guidance specifically states "Don't create management groups for production, testing, and development environments." at https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups. It would be better if the docs were consistent, and this page used an example management group hierarchy that aligned with our CAF guidance.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.