You Just Inherited an Azure Subscription. What to Do First

Somebody left, or somebody decided you were technical enough, and now the Azure subscription is yours. There was no handover document. There is a portal, a login, and a quiet expectation that you already understand what is in there.

I know the shape of this. My first job was managing servers, and I was the person the team came to whenever something needed doing. Being the one who gets asked is very different from being the one who knows.

So here is the order I would actually go in. The first three are about not breaking anything. Learning how it all works comes after.

First, find out what you have

In the portal, go to All resources and remove every filter. That is the real list. Not the resource groups somebody named nicely, the actual inventory.

Sort it by type and read it once, slowly. You are not trying to understand any of it yet. You are answering one question: is anything here a surprise? A database in a region nobody mentioned. A machine called test-DO-NOT-DELETE. Three resource groups that look like the same project at different times.

Write down the ten things that look important. That list is your map for everything that follows.

Second, find out who else can touch it

Open the subscription, then Access control (IAM), then Role assignments. This tells you who else can change things, and it is usually more people than anybody expects.

Look for two things. People who have left the company and still hold a role. And service principals, which are the logins that applications and pipelines use, created for projects that may have finished years ago.

Do not start removing them today. You do not yet know what would break, and a pipeline that stops the day you take over is a bad first week. Write them down. That is a real task for next month, with somebody who remembers the projects.

Third, lock the thing that would end your week

This is the one that matters and almost nobody does it early.

Azure has a feature called resource locks. You put one on a subscription, a resource group, or a single resource, and here is the part worth understanding: Microsoft says "the lock overrides any user permissions", and "unlike with role-based access control, you use management locks to apply a restriction across all users and roles".

Across all users and roles. Including you. Including the Owner. That is the point of it.

There are two kinds. In the portal they are called Delete and Read-only. On the command line the same two are CanNotDelete and ReadOnly. Delete lets people carry on working normally and only stops removal. Read-only freezes the thing entirely.

Start with Delete locks, on the production database and on anything holding data you could not recreate. Delete is the safe one to reach for, because it changes nothing about how the resource runs day to day.

It also protects you against the mistake that actually happens. Deleting a resource group deletes everything inside it, and resource groups are easy to delete by accident because the button sits right there. With a Delete lock on even one resource inside it, Microsoft's behaviour is exactly what you want: "If you have a Delete lock on a resource and attempt to delete its resource group, the feature blocks the whole delete operation... A partial deletion isn't possible."

One lock on the database protects the whole group from a wrong click. Locks also inherit downward, so a lock on a resource group covers everything in it, including resources somebody adds later.

What locks do not do, before you trust them too much

Read this bit properly, because the gap here catches experienced people.

Microsoft: "Locks only apply to control plane Azure operations and not to data plane operations." In plain terms, a lock protects the resource from being deleted or reconfigured. It does not protect what is inside it.

They spell it out for storage: "A read-only lock or cannot-delete lock on a storage account doesn't protect its data from being deleted or modified. It also doesn't protect the data in a blob, queue, table, or file."

So a locked storage account cannot be deleted, and somebody with access can still empty it. A lock is not a backup. It stops the resource disappearing, which is a different problem from the data disappearing, and you need an answer to both.

Read-only locks in particular have edges worth knowing before you use them. A read-only lock on a resource group containing a virtual machine "prevents all users from starting or restarting a virtual machine". A read-only lock on a subscription "prevents Azure Advisor from working correctly", so you lose the free cost advice. And a cannot-delete lock on the resource group Azure Backup created makes backups fail, because the service cannot clean up its own old restore points.

None of that makes locks a bad idea. It makes Delete locks the right default and Read-only the one you reach for deliberately.

To set one you need Owner or User Access Administrator. If you have just inherited the subscription and cannot create a lock, that is the first thing to ask for, and it is a very easy thing to justify.

Fourth, put a number on the money

Go to Cost Management, set a budget for roughly what the subscription spends now, and turn on an anomaly alert. Both are free.

You are not trying to control spend yet. You are buying yourself a tap on the shoulder. Without this, the first you hear about something going wrong is the invoice, four weeks after it started.

Then learn the shape

Azure stacks in four levels: management group, then subscription, then resource group, then the resource itself. Permissions flow down that chain, which is why somebody with a role at the subscription level has it on everything underneath without appearing anywhere lower.

A resource lives in exactly one resource group. That is the boundary that matters most day to day, and it is the one people get wrong when they assume a resource group is a folder. It behaves more like a container with a single delete button.

Everything else you can learn when you need it. Those two facts explain most of what confuses people in the first month.

What not to do in week one

Do not tidy up. The urge is strong and it is the wrong instinct. Every unexplained resource in an inherited subscription is either waste or load bearing, and you cannot tell which yet. Waste costs money. Load bearing costs your weekend.

Do not rename things to make sense to you. Names show up in scripts, pipelines, alerts and dashboards you have not found yet.

Do give things tags. A tag is additive, it breaks nothing, and a tag saying who owns a resource and when you last looked at it is the single most useful thing you can leave for the version of you six months from now.

The shorter way

The honest problem with everything above is that it is a lot to hold when you did not ask for the job, and the answers go stale the moment somebody changes something.

That is why Liberra exists. Connect the subscription and it builds an index of what is actually in there, so instead of reading All resources and hoping, you ask: what is running, what does it cost, what is exposed, what depends on this database if I touch it.

It explains the why as it goes, which matters more than the answer when you are learning somebody else's subscription.

And it cannot delete anything. Not a setting, not a permission we grant carefully. The delete commands are blocked in the code. Every change that writes stops and waits for you to approve it, and it tells you what it is about to do in plain English before you decide.

When you have just been handed something you are afraid of breaking, a tool that physically cannot break it is the right kind of help.

Founder, Liberra AI