Build Lab — Assign one policy and watch it refuse a deployment

Build brief

Unit: 1 — Identity, governance, monitoring
You need: Your own Azure subscription
Time: 20 minutes
Cost: No billable resource is created
Interface: Azure CLI

This is the hands-on twin of the design lab "Put each control at the scope that owns it". There you decided where a control belongs. Here you assign one, put a subscription under it, and watch Azure refuse a deployment that breaks it — which is the part that makes the scope argument stop being abstract.

Before you start

The Azure CLI installed, and az login completed.
Permission to create management groups. On many tenants this is restricted; if the first command fails with an authorization error, skip to If it did not work — that failure is itself worth understanding.
Your subscription id to hand: az account show --query id -o tsv

What you are building

Loading Diagram...

Figure 1 — Mermaid diagram

Step 1 — create the management group

bash

az account management-group create \
  --name bb-lab-eu \
  --display-name "BB Lab — EU boundary"

You should get a JSON object back with "name": "bb-lab-eu". Creation is asynchronous; if a later command says the group is not found, wait a few seconds and retry.

Step 2 — move your subscription under it

bash

az account management-group subscription add \
  --name bb-lab-eu \
  --subscription "$(az account show --query id -o tsv)"

This is the step the design lab was really about: the subscription now inherits anything assigned at that group.

Step 3 — find the built-in policy by name

bash

az policy definition list \
  --query "[?displayName=='Allowed locations'].{name:name, id:id}" -o table

Look up the definition by display name rather than pasting a GUID — the id is stable, but looking it up is the habit that survives the id changing and works for any built-in.

Step 4 — assign it at the management group

bash

az policy assignment create \
  --name bb-lab-allowed-locations \
  --display-name "BB Lab — EU regions only" \
  --scope "/providers/Microsoft.Management/managementGroups/bb-lab-eu" \
  --policy "$(az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv)" \
  --params '{"listOfAllowedLocations":{"value":["westeurope","northeurope"]}}'

One assignment. Note the scope: a management group path, not a subscription or resource group.

Step 5 — prove it works, in both directions

Allowed region — this should succeed:

bash

az group create --name bb-lab-ok --location westeurope

Disallowed region — this should be refused:

bash

az group create --name bb-lab-blocked --location eastus

Checkpoint

The second command must fail with a policy error naming RequestDisallowedByPolicy. If it succeeded, the assignment has not propagated yet — policy evaluation is not instant. Wait a few minutes and try again before assuming something is wrong.

Look carefully at what refused you. It was not a role, a lock, or a quota. It was a rule assigned once, at a scope above the subscription, that you never attached to this resource group — because the resource group did not exist when you assigned it. That is inheritance, and it is the entire argument of the design lab in one error message.

Why this matters on the exam

Multiple choice · MediumPolicy scope and inheritance

You just watched a policy assigned at a management group refuse a deployment into a resource group created afterwards. Which exam claim does that experiment support?

Teardown

Run all of it. The first two commands remove what could affect future deployments.

bash

az policy assignment delete \
  --name bb-lab-allowed-locations \
  --scope "/providers/Microsoft.Management/managementGroups/bb-lab-eu"

az group delete --name bb-lab-ok --yes --no-wait

az account management-group subscription remove \
  --name bb-lab-eu \
  --subscription "$(az account show --query id -o tsv)"

az account management-group delete --name bb-lab-eu

Verify nothing is left:

bash

az policy assignment list --query "[?name=='bb-lab-allowed-locations']" -o table
az account management-group list --query "[?name=='bb-lab-eu']" -o table

Both should return nothing.

If it did not work

The three failures worth understanding

'Authorization failed' on step 1
Creating management groups can be restricted at the tenant, and by default the creator needs the right at root scope. This is not a broken lab — it is the governance model working. If you cannot create one, read steps 3-5 and run the policy assignment against your SUBSCRIPTION scope instead: everything works the same except the inheritance-to-future-subscriptions property, which is the one thing you cannot demonstrate that way.

Go back to the design lab "Put each control at the scope that owns it" and re-answer the four cards. The forty-assignments question in that brief should now read differently: you have seen the window where a subscription exists but its rule does not.

Build Lab — Assign one policy and watch it refuse a deployment

Build brief

Unit: 1 — Identity, governance, monitoring
You need: Your own Azure subscription
Time: 20 minutes
Cost: No billable resource is created
Interface: Azure CLI

Before you start

The Azure CLI installed, and az login completed.
Permission to create management groups. On many tenants this is restricted; if the first command fails with an authorization error, skip to If it did not work — that failure is itself worth understanding.
Your subscription id to hand: az account show --query id -o tsv

What you are building

Loading Diagram...

Figure 1 — Mermaid diagram

Step 1 — create the management group

bash

az account management-group create \
  --name bb-lab-eu \
  --display-name "BB Lab — EU boundary"

You should get a JSON object back with "name": "bb-lab-eu". Creation is asynchronous; if a later command says the group is not found, wait a few seconds and retry.

Step 2 — move your subscription under it

bash

az account management-group subscription add \
  --name bb-lab-eu \
  --subscription "$(az account show --query id -o tsv)"

This is the step the design lab was really about: the subscription now inherits anything assigned at that group.

Step 3 — find the built-in policy by name

bash

az policy definition list \
  --query "[?displayName=='Allowed locations'].{name:name, id:id}" -o table

Look up the definition by display name rather than pasting a GUID — the id is stable, but looking it up is the habit that survives the id changing and works for any built-in.

Step 4 — assign it at the management group

bash

az policy assignment create \
  --name bb-lab-allowed-locations \
  --display-name "BB Lab — EU regions only" \
  --scope "/providers/Microsoft.Management/managementGroups/bb-lab-eu" \
  --policy "$(az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv)" \
  --params '{"listOfAllowedLocations":{"value":["westeurope","northeurope"]}}'

One assignment. Note the scope: a management group path, not a subscription or resource group.

Step 5 — prove it works, in both directions

Allowed region — this should succeed:

bash

az group create --name bb-lab-ok --location westeurope

Disallowed region — this should be refused:

bash

az group create --name bb-lab-blocked --location eastus

Checkpoint

Why this matters on the exam

Multiple choice · MediumPolicy scope and inheritance

You just watched a policy assigned at a management group refuse a deployment into a resource group created afterwards. Which exam claim does that experiment support?

Teardown

Run all of it. The first two commands remove what could affect future deployments.

bash

az policy assignment delete \
  --name bb-lab-allowed-locations \
  --scope "/providers/Microsoft.Management/managementGroups/bb-lab-eu"

az group delete --name bb-lab-ok --yes --no-wait

az account management-group subscription remove \
  --name bb-lab-eu \
  --subscription "$(az account show --query id -o tsv)"

az account management-group delete --name bb-lab-eu

Verify nothing is left:

bash

az policy assignment list --query "[?name=='bb-lab-allowed-locations']" -o table
az account management-group list --query "[?name=='bb-lab-eu']" -o table

Both should return nothing.

If it did not work

The three failures worth understanding

'Authorization failed' on step 1
Creating management groups can be restricted at the tenant, and by default the creator needs the right at root scope. This is not a broken lab — it is the governance model working. If you cannot create one, read steps 3-5 and run the policy assignment against your SUBSCRIPTION scope instead: everything works the same except the inheritance-to-future-subscriptions property, which is the one thing you cannot demonstrate that way.

Build Lab — Assign one policy and watch it refuse a deployment

Build Lab — Assign one policy and watch it refuse a deployment

Build brief

Before you start

What you are building

Step 1 — create the management group

Step 2 — move your subscription under it

Step 3 — find the built-in policy by name

Step 4 — assign it at the management group

Step 5 — prove it works, in both directions

Checkpoint

Why this matters on the exam

Teardown

If it did not work

The three failures worth understanding

'Authorization failed' on step 1

Next

Build Lab — Assign one policy and watch it refuse a deployment

Build Lab — Assign one policy and watch it refuse a deployment

Build brief

Before you start

What you are building

Step 1 — create the management group

Step 2 — move your subscription under it

Step 3 — find the built-in policy by name

Step 4 — assign it at the management group

Step 5 — prove it works, in both directions

Checkpoint

Why this matters on the exam

Teardown

If it did not work

The three failures worth understanding

'Authorization failed' on step 1

Next