Managing Azure Subscriptions
Managing Resource Groups
The course is part of these learning pathsSee 1 more
As an IT professional tasked with managing resources in Azure, it’s important to understand key administrative roles and permissions within a subscription and within a resource group. It’s also important to know how to leverage Role Based Access Control (RBAC) for managing such administrative roles and permissions.
In the first part of this course, you will learn about Azure subscriptions. You will learn about key roles within a subscription, including the owner role, account administrator role, service administrator role, and the co-administrator role. You’ll also learn how to manage these roles by using RBAC. We’ll also cover subscription policies and the role they play in the management of an Azure subscription.
In the second part of the course, we’ll talk about resource groups in Azure. We’ll touch on what they do and how they are managed. You will learn how to secure resources within a resource group via resource policies and resource locks. You’ll also learn about resource tagging and how it can be used to manage and group Azure resources.
Rounding out this course, we’ll cover the process of moving resources from one resource group to another, as well as the deletion of resource groups altogether.
- Understand the Owner Role
- Understand the Account Administrator Role
- Understand the Co-Administrator Role
- Understand the Service Administrator Role
- How to Manage Roles and Permissions with RBAC
- Understand Subscription Policies
- Understanding the Purpose of Resource Groups
- How to Leverage Resource Group Policies
- How to Use Resource Locks to Protect Resources
- How to Leverage Resource Tags
- Moving Resources Between Resource Groups
- Removing Resource Groups
- IT Professionals interested in becoming Azure cloud architects
- IT Professionals preparing for Microsoft’s Azure certification exams
- General knowledge of IT infrastructure
- General knowledge of the Azure environment
Day-to-day operations will sometimes require that resources be moved from one resource group to another. While this is possible, it's important to note that when moving resources between resource groups, both the source group and the target group are locked during the operation. Write and delete operations are both blocked on the resource groups involved until the move completes. As such, resources can't be added, updated, or deleted in the locked resource groups while the move is in progress. However, this doesn't mean the resources themselves are frozen. For example, if you move an application server and its database to a new resource group, the application experiences no downtime. It continues to function as normal. It's important to note that the location of a resource cannot be changed. Moving a resource only moves it to a new resource group. While the new resource group may have a different location, this fact doesn't change the location of the resource itself being moved to the new resource group. Before moving a resource to a new resource group, there are some important steps to perform to prepare for such a move.
By taking these steps, errors can be avoided. For starters, the source and destination subscriptions must exist within the same Azure Active Directory tenant. The destination subscription must be registered for the resource provider of the resource being moved. If the destination subscription isn't registered for that resource type being moved, you'll see an error stating that the subscription is not registered for a resource type. This often happens when moving a resource to a new subscription, but that subscription has never been used with that resource type before. The account moving the resources must have the permissions you see on your screen. Before moving resources, ensure the subscription quotas for the subscription you're moving the resources to supports the resources you plan to move. If moving the resources will cause the destination subscription to exceed its limits, an increase in the quota for that resource must first be requested. When moving resources, it's best to break large moves into separate, smaller move operations. As a matter of fact, Resource Manager will immediately fail if there is an attempt to move more than 800 resources in a single move operation. That's said, a move of fewer than 800 resources may also fail, but that would be due to timeouts and other miscellaneous reasons.
About the Author
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.