abccccc.pdf

In this lesson, we're going to explore the benefits and usage of management groups. I previously talked about what we may end up with is multiple subscriptions. Hey, I've got maybe multiple subscriptions for development, maybe multiple subscriptions for different purposes for production. Maybe there...

In this lesson, we're going to explore the benefits and usage of management groups. I previously talked about what we may end up with is multiple subscriptions. Hey, I've got maybe multiple subscriptions for development, maybe multiple subscriptions for different purposes for production. Maybe there's a whole bunch of different subscriptions over different business units. And we talked about the idea that I can have role-based access control and policy and budgets at these various levels. But what about if I have tens and hundreds of subscriptions and I want to be able to do role-based access control and policies and budgets that apply to multiple and not have to do it on a per subscription basis? This is where management groups come in. We talked about the idea of an Azure AD tenant, and every subscription trusts one and only one Azure AD tenant. So I can think about at the top, I have the Azure AD tenant for my particular organization. Now, by default, without doing anything else, I'm always going to have a root management group. And then what I can manually add is a hierarchy. So I can actually create a complete hierarchy of management groups. Now I can go up to six levels of management groups that do not include the root; it does not include the subscriptions underneath. Now don't overcomplicate it; we create what makes sense for our particular requirements. Now maybe in this case, I've got the idea that, well, these subscriptions are going to tie up to this particular management group. Maybe this is dev, maybe this is prod. I might also have the idea of I might create a layer for different countries. Particularly, there's a whole set of different ways I can think about constructing my management groups. But the key point is once again, what can I do at a management group? Well, a management group, I can apply budget; I can apply role-based access control, and I can apply policy, you guessed it. And once again, they're inherited down. So if I set a role-based access control on production, it would get inherited to the child management groups, to the subscriptions, to the resource groups, to the resources, same for policy budget would roll up to whatever level it is. So the whole point of the management group is it's there to help me manage a group of subscriptions. And by management, we're talking about, hey, I want to apply a certain policy or a certain role-based access control. I want a certain budget. And what I'll do is near the top, there'll be more general role-based access control, more general policies. Then as I get closer to the resource, I'll get more specific because I can still have role-based access control on a sub, still have them on a particular resource group, even on a particular resource that we try and avoid that it's hard to manage. So I could have a very general set of maybe production policies and RBAC. And then for a particular application, it might have its own set of RBAC, so they get inherited through them. So I'm going to create what makes the most sense for my company. I might also have geography in here. If we go and look, it's super simple to see. So I'm just looking at my management groups. We can see I have that idea of I'm going to expand, extend this out. I have the idea of, well, yeah, there's my tenant root group. Then I created an all Savile Tech subscriptions management group under which I actually have two subscriptions. Then I also have a dev management group and a production management group. If I look at the management group, let's just pick this all Savile Tech subscriptions. Well, what can I do on there? Once again, we have this idea of access control; we have the idea of policy, and we have the idea of budgets. So I can set all of those things. If I go and look, for example, access control and look at role assignments, I can actually see well, the owner is John Savile on this resource. We can actually see I've inherited a certain right from the parent management group, and this applies all the way down. So if I then went and actually looked at a certain subscription, let's actually then look at its access control. When I look at the scope of various permissions, hey, look, I can see some of them were inherited from the management group. If I was to then go and look at a particular resource group in this subscription, we can kind of see this going all the way. I'm trying to find my demo VM. There we go. If I look at its access control and look at its role assignments, I can see well, that resource group has some inherited from the subscription. I can see some were inherited from the management group, and there might even be ones that were set directly on this resource itself, some actually from the root as well. And that would actually apply into the individual resource. If I now want to look at saying as basic as a disk and also its access control, well, they all got inherited down as well. So the key point here is what do we do with management groups? They're there to help us manage groups of subscriptions and the resource within for the purposes of role-based access control, policy, and potentially rolling up a certain budget. So I'm going to create them what makes sense for me. Could be geography, could be business unit; it could be environment, for example, dev or production. It's there to make our life easier, so don't overcomplicate it; create them where it will actually bring you benefit.