In the previous lesson you created a resource group and a storage account by clicking, and some questions were left hanging: what really is a resource group? Why does deleting it remove everything it contains? Why are tags not inherited? And how is it possible that the portal, the command line and a template all do exactly the same thing?

The answer to all of them is the same: Azure Resource Manager (ARM), Azure's control plane. Understanding ARM is what separates someone who "knows how to use the portal" from someone who understands Azure. This lesson is the most important one in the module conceptually, and its practical consequences — organization, governance, cost, protecting production — will stay with you right up to the last module.

1. What Azure Resource Manager is
2. The complete Azure hierarchy
3. Resource providers and their registration
4. The resource ID and how to read it
5. Real criteria for grouping resources
6. Resource locks: protecting production
7. Moving resources between groups and subscriptions
8. Tags: what they are really for
9. Contoso Airlines' tagging scheme
10. ARM templates and Bicep as a concept
11. Subscription limits and quotas
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Azure Resource Manager is Azure's management service: the single door through which every operation to create, modify, read and delete resources passes. It is not a tool you use directly; it is the API behind all the tools.

Practical consequences of this design, all of them verifiable:

• Complete consistency. Whatever you can do through the portal you can do through the CLI, and vice versa. If something appears in one tool and not in another, it is usually a matter of version, not capability.
• A single security point. RBAC permissions (module 4) and policies (module 4) are enforced in ARM, so they apply equally to every tool. You cannot "sidestep" a policy by using the CLI.
• Unified auditing. The activity log you saw in the previous lesson captures operations wherever they come from.
• Declarative deployments. ARM accepts templates that describe the desired state, works out the creation order and parallelizes whatever it can.
• Idempotent operations. Sending the same desired state twice does not create two resources: it converges on the same result. This property is the foundation of infrastructure as code.

One nuance that avoids future confusion: ARM governs the control plane (creating a storage account, changing its tier). The data plane (uploading a blob, running a SQL query) is served by each service through its own endpoint and its own permissions. Two planes, two access models.

Four levels, from the broadest to the narrowest scope. Each one has a different purpose and is where certain things get applied.

Iron rules you have to memorize:

1. Every resource belongs to exactly one resource group, and that group to exactly one subscription.
2. Permissions and policies are inherited downwards. A permission granted at the subscription applies to all its groups and resources.
3. Tags are NOT inherited. I insist because it is counterintuitive precisely because of the previous point. We will look at it in section 8.
4. A resource group can contain resources from different regions. Its own region only says where the group's metadata is stored.
5. Deleting a resource group deletes all its contents, with no exceptions and no recycle bin.

About management groups: Contoso does not need them yet with two subscriptions, but they are the right tool as soon as there are several. They let you, for example, apply a policy of "deployment is only allowed in European regions" to everything hanging off the Producción group, without repeating it subscription by subscription. They are developed in lesson 04-06 (Azure Policy).

A resource provider is the ARM component that knows how to create and manage a family of resources. Its name takes the form Microsoft.<Family>:

Each provider must be registered in the subscription before you can use it. The portal registers the provider automatically when you create the first resource of that family, which is why you normally never notice. But when you deploy through the CLI or with a template, an unregistered provider produces a cryptic error along the lines of "The subscription is not registered to use namespace 'Microsoft.X'".

Providers also determine which API versions are available and in which regions each resource type exists:

Every Azure resource has a unique, global identifier. It appears in logs, in error messages, in templates and in any automation, so you need to be able to read it at a glance.

Broken down by segment:

Child resources nest the pattern. A database inside a SQL server:

And some resources live directly in the subscription, with no group (for example, a policy assignment at subscription level):

Getting a resource's ID from the CLI:

The question everybody asks: "how many resource groups do I create, and what do I put in each one?". The professional answer is not simply "one per project".

Put in the same group whatever is born and dies together. If you are going to delete the booking application, do you want the corporate virtual network to disappear too? No. Then they do not go in the same group.

• "Everything together": a single group with 300 resources. Impossible to grant permissions sensibly, impossible to delete anything safely.
• "One per resource": 300 groups with one resource each. All the management overhead and none of the benefits.
• "By resource type": one group for all the VMs, another for all the databases. It sounds tidy and it is a disaster: nothing shares a lifecycle and you cannot delete a project without going piece by piece.

The last three will be filled in during modules 2, 4 and 7. Notice that the network is separate: it is exactly the kind of shared, long-lived resource that must not die with an application.

A lock prevents destructive operations even for someone with owner permissions. It is the safety net against human error, not against attack.

They can be applied to a subscription, a resource group or an individual resource, and they are inherited downwards: a lock on the group protects all its resources.

From the portal: resource or group → Locks → Add.

ReadOnly is more aggressive than it looks, and it causes surprises:

• A ReadOnly lock on a group containing a storage account prevents listing the access keys, because that operation is technically a write (listKeys). Applications that were working stop working.
• A ReadOnly lock on a virtual machine prevents starting or stopping it.
• Locks affect the control plane, not the data plane: with CanNotDelete on a storage account, nobody can delete the account, but anyone with data permissions can still delete the blobs inside it. There are other protections for that (retention, soft delete), covered in module 2.

Recommended practice at Contoso: CanNotDelete on all production groups and on stateful resources (databases, storage accounts, Key Vault). ReadOnly only in very well justified cases and after testing first.

Resources can be moved, but with rules. It is a common operation when you reorganize or when a project moves from development to production.

• Not every resource can be moved. There is an official list by resource type; always check first. Common examples of restrictions: VPN gateways, some networking configurations and certain resources with regional dependencies.
• Moving does not change the region. A resource in West Europe stays in West Europe even if you move it to a group whose region is a different one. To "move it to another region" you have to recreate or replicate it.
• During the move, the source and destination groups are locked for writes until it finishes.
• Dependent resources have to be moved together. A VM needs to go with its network interface, its disks and its public IP.
• The identifiers change, because the ID includes the group. Any script, alert or policy assignment pointing at the old ID will stop working.
• Permission assignments and policies do not travel with the resource: those of the new scope apply instead. Review access after moving.
• Moving between subscriptions also requires both to be in the same Microsoft Entra ID tenant and the providers to be registered in the destination one.

Practical tip: for an important move, validate first:

A tag is a name-value pair attached to a subscription, a resource group or a resource. Each resource accepts up to 50 tags.

Tags look like decoration right up until the company has 400 resources. Then they become the only way to answer critical questions:

In other words: cost, ownership and compliance. Without tags, the module 8 conversation with Nuria Peña ("why did we spend EUR 4,000 this month?") is impossible to hold, because Cost Management will be able to tell you that you are spending on virtual machines, but not whose they are.

Tags are not inherited. A tag placed on a resource group does not appear on the resources it contains. It is Azure's number one trap for people coming from the portal, because everything else (permissions, policies, locks) is inherited.

Why does it matter so much? Because cost reports are aggregated by the tag on the resource that generates the charge. If you only tagged the group, your reports by centro-coste will come out empty.

The three real solutions:

1. Tag at creation time, always, in the Tags tab or with the --tags parameter. It is the basic discipline.
2. Azure Policy with the Modify effect: a policy that automatically adds to the resource the tag inherited from the group. This is the professional solution and it is covered in lesson 04-06.
3. Infrastructure as code: the tags are written into the template and applied automatically on every deployment (lesson 05-06).

Other operational details:

• Tag names are case-insensitive for operations, but values do preserve case exactly as you write them. Pick a format and stick to it: produccion and Produccion will be counted as different values in reports.
• Do not put secrets in tags: they are visible to anyone with read permission.
• Some resource types do not accept tags; they are a minority, but they exist.

Typical output of the last command:

And in the portal: resource or group → Tags section → add name/value pairs → Apply. To tag many resources at once, use All resources, tick the boxes and click Assign tags.

Marta Ríos publishes this scheme as an internal standard. It is mandatory on every resource and we will use it throughout the course.

Rules of the scheme:

1. All values in lowercase and without accents, so that reports group properly.
2. propietario is always a person, not a department: departments do not answer the phone.
3. Resources missing the four mandatory tags are flagged as non-compliant and will appear in the compliance report once we roll out Azure Policy (lesson 04-06).

Applied to the resources you already know:

You already know that ARM accepts declarative descriptions of the desired state. Those descriptions are ARM templates (JSON) and Bicep (a more readable language that compiles to JSON). Here we only cover the concept: the full treatment is in lesson 05-06.

An ARM template in JSON, reduced to the bare minimum:

The same thing in Bicep, far more readable:

Three ideas to hold on to:

• It is declarative: you describe the result, not the steps. ARM works out what has to be created, modified or left alone.
• It is idempotent: deploying five times leaves the same result as deploying once.
• It is versionable: the template lives in Git, is reviewed in a pull request and is deployed from a pipeline (module 5).

A learning trick you already saw in the portal: on any resource, the Automation → Export template section gives you the JSON of the existing resource. It is the best way to learn the syntax from something that already works.

Azure is not infinite. Every subscription has limits (some fixed, some raisable by opening a support request). Finding out about a limit in the middle of an urgent deployment is an unpleasant and avoidable experience.

The exact figures change; always check "Azure subscription and service limits, quotas, and constraints" in the official documentation.

The quota that causes beginners the most trouble is VM cores per region and family: a new free account may have room for very few machines, and the deployment error ("Operation could not be completed as it results in exceeding approved quota") is disconcerting because it looks like a deployment failure and it is not.

Checking your real quota:

To raise a quota: portal → Subscriptions → your subscription → Usage + quotas → Request increase. It is usually resolved in minutes or hours.

• Creating a catch-all resource group. If you do not know why a resource is in there, it is in the wrong place. Group by lifecycle.
• Believing tags are inherited. They are not. Tag each resource at creation time or automate it with Azure Policy.
• Tagging with inconsistent values. Produccion, produccion, PRO and prod are four different values in cost reports, and the report becomes useless. Fix the vocabulary and stick to it.
• Applying ReadOnly casually. It can break applications by preventing operations that look like reads but are writes (such as listing keys). Test in development first.
• Trusting CanNotDelete to protect data. It protects the resource, not its contents. The blobs inside can still be deleted.
• Moving resources without checking the supported list or warning people that the IDs will change. Afterwards, review alerts, scripts and permissions.
• Ignoring provider registration when automating in a new subscription. Register the providers at the start of the script.
• Discovering the core quota in the middle of a deployment. Check it beforehand with az vm list-usage.
• Cost tip: resource groups, tags and locks are free. Use them without hesitation: they are the cheapest governance infrastructure there is, and the one that saves the most money in the medium term.

Contoso Airlines is also going to launch a loyalty program ("Contoso Miles"), with its own website, its own database and its own cost center CC-2077, owned by Diego Salas. It will share the existing corporate virtual network and Key Vault.

1. Propose the resource groups needed and what each one contains.
2. Justify why the virtual network must not be in the project's group.
3. Write the set of mandatory tags for the Contoso Miles production group.

1. Break this ID down into its five parts and state what each one is:

2. Build the ID a subnet called snet-web inside that same virtual network would have.
3. Write the CLI command that returns only the ID of the sttarjetascontosopro storage account in the rg-contoso-reservas-pro group.

1. Write the commands to create the rg-contoso-reservas-pro group in West Europe with the four mandatory tags and apply a CanNotDelete lock to it.
2. Write the command that lists all the resources in the subscription tagged with proyecto=contoso-reservas.
3. Marta tries to delete the group from the portal and it fails. Explain what is happening and what she must do to succeed legitimately.
4. Diego applies ReadOnly to the development group and, the next day, the test application stops starting because it cannot read the storage account keys. Explain why.

Solution 1:

1. Proposed groups:

2. The virtual network has a different lifecycle: it outlives projects and is shared by several applications. If it lived inside the project's group, retiring Contoso Miles would delete everyone's network, and on top of that you would have to give the developers permissions over an infrastructure resource they should not be administering.

3. Tags for the Miles production group:

Solution 2:

1. Breakdown:

2. The subnet ID (a child resource, so type/name nest):

3. Command:

Solution 3:

1. Creation and lock:

2. Listing by tag:

3. The CanNotDelete lock prevents deletion even though Marta is the owner. To delete it legitimately she must first remove the lock (az lock delete or portal → Locks), which requires permission over Microsoft.Authorization/locks, and then delete the group. That extra, deliberately inconvenient step is exactly the point: it forces a conscious decision.

4. Because ReadOnly blocks any write operation on the control plane, and retrieving a storage account's keys is implemented as the listKeys action, which ARM classifies as a write. The application cannot retrieve the keys and fails to start. The fix: remove the ReadOnly lock (use CanNotDelete instead) and, better still, stop using keys and move to managed identities (lesson 04-02).

Azure Resource Manager is Azure's single control plane: the portal, the CLI, PowerShell, the SDKs and templates all talk to the same API, and that is why permissions, policies and auditing are consistent no matter where you come from. On top of it sits the hierarchy management group → subscription → resource group → resource, where permissions and policies are inherited downwards... and tags are not.

You have learned to read a resource ID, to register providers, to group resources by lifecycle and environment (avoiding "everything together" and "one per type"), to protect production with locks — knowing the traps of ReadOnly and the limits of CanNotDelete — to move resources in the knowledge that IDs change and permissions do not travel, and to design a serious tagging scheme: Contoso Airlines', with entorno, proyecto, centro-coste and propietario as mandatory. You have also seen what ARM templates and Bicep are about, and where the limits and quotas are that are worth checking before rather than after.

You will have noticed that in this lesson the examples were, almost all of them, commands. That is no accident: governing dozens of resources with tags and locks by clicking does not scale. In the last lesson of the module, Azure CLI, PowerShell and Cloud Shell, you will learn to drive Azure from the command line and you will write your first complete, parameterized and idempotent script, which creates the whole base of Contoso Airlines and knows how to clean up after itself.