The Azure Landing Zone Prerequisite That Blocks Most First Deployments

Global Admin is not what you think it is.

Here is the part that catches people. By default, a Microsoft Entra Global Administrator does not have permission to manage Azure resources.

Read that again, because it contradicts the mental model most of us carry. Global Administrator sounds like the top of the tree. In Entra ID, it is. But Entra ID and Azure resource management are two separate permission planes, and holding the crown in one does not grant you anything in the other.

Think of it like being the building manager with a master key to every apartment, then discovering the parking garage is run by a different company entirely. Your key means nothing at that gate until someone grants you access.

Azure Landing Zone deployments need the parking garage.

Why ALZ specifically hits this wall

Most Azure work never exposes the gap. If you are deploying a VM, a storage account, or an App Service, you are working inside a subscription, where your Owner role is real and sufficient.

An Azure Landing Zone is not that. It is the full platform foundation: the management group hierarchy, platform subscriptions for Management, Identity, and Connectivity, Azure Policy guardrails, centralized logging, and the connectivity layer. Creating management groups and placing subscriptions under them happens above the subscription, at the tenant root.

Subscription-scoped Owner cannot create management groups. It does not matter how many subscriptions you own. The scope is simply wrong for the job, and the deployment fails at the first step that reaches for the tenant root.

This is also why the fix is not "grant myself more subscriptions."

The fix, in order

Step 1: Enable access management for Azure resources.

Sign in to the Azure portal as a Global Administrator. Go to Microsoft Entra ID, then Properties. Set "Access management for Azure resources" to Yes.

This elevates your account to User Access Administrator at the tenant root "/" scope. It is the switch that connects the two permission planes.

Step 2: Assign Owner at the tenant root.

Being User Access Administrator lets you assign roles. It does not make you Owner. You still need the Owner assignment at "/", and there is no portal UI for it. This one is CLI or PowerShell only.

Azure CLI:

bash
az login
az role assignment create \
--assignee-object-id $(az ad signed-in-user show --query id -o tsv) \
--assignee-principal-type User \
--role Owner \
--scope "/"

PowerShell:

powershell
Connect-AzAccount
New-AzRoleAssignment -ObjectId (Get-AzADUser -SignedIn).Id -RoleDefinitionName Owner -Scope "/"

Step 3: Wait, then refresh your token.

Permission at tenant root scope can take up to 15 minutes to propagate. Your existing token does not carry the new assignment, so sign out and sign back in before deploying.

This step is the one people skip, and skipping it produces the most confusing failure of the three. The permission is correct. The command is correct. The token is stale, so Azure rejects you anyway, and the error points nowhere useful.

Step 4: Remove the access when you are done.

After the deployment completes, remove the Owner assignment at "/" and set the "Access management for Azure resources" toggle back to No. Ongoing operations do not need it. Standing tenant-root Owner is a large blast radius to leave lying around for no reason.

Deploy at the right scope

While we are here, the second most common failure: deploying at subscription scope.

The ALZ initial deployment targets the tenant root. That means az deployment tenant create or az deployment mg create, not az deployment sub create. If you copied a command from an older guide, check this. Subscription-scoped deployment cannot create the management group hierarchy that the entire landing zone is built on.

If you are automating it

Deploying through a pipeline changes the identity but not the requirement. Your service principal, or a managed identity with federated credentials, needs Owner on the "/" root management group.

Contributor is not enough, and the reason is specific: ALZ creates role assignments as part of the deployment, and Contributor cannot assign roles. This is a common misconfiguration in pipelines that were scoped with least privilege in mind and then failed for a reason that looked unrelated.

The pattern worth taking away

The reason this prerequisite is so easy to miss is that nothing about the failure points at it. You have the highest role you know about. The command looks right. The docs you found do not mention elevation, because they assumed a tenant where someone already handled it.

Permission problems in Azure are usually scope problems in disguise. When something fails and your role looks sufficient, the question is rarely "do I have enough power." It is "do I have it at the right level."

Check the scope before you check anything else. It will save you an afternoon.

If you found this useful, hit the Subscribe button below to get more articles like this delivered straight to your inbox.

Want to see what our AI agents do with a problem like this? Start a free trial and throw your trickiest ticket at them.

What is the Azure error message that has cost you the most time? Tell me in the comments.