Grant one identity Reader on one resource group, and read Defender for Cloud's free posture

Steps

1. Create the lab's resource group, and a user-assigned managed identity in it to act as an application's identity:

az group create --name az900-lab11-rg --location eastus
az identity create --name az900-lab11-id --resource-group az900-lab11-rg --location eastus

A managed identity is a security principal that Azure creates and manages, so no password or secret exists for anyone to leak. It costs nothing. 2. Compare what four built-in roles allow:

az role definition list --name Reader --query '[0].permissions[0].actions' -o tsv
az role definition list --name Contributor --query '[0].permissions[0].notActions' -o tsv
az role definition list --name "User Access Administrator" --query '[0].permissions[0].actions' -o tsv
az role definition list --name Owner --query '[0].permissions[0].actions' -o tsv

Reader allows */read: view everything, change nothing. Contributor allows everything except what its notActions list removes, and the first entries there, Microsoft.Authorization/*/Delete and Microsoft.Authorization/*/Write, are exactly the power to grant or remove access. User Access Administrator has Microsoft.Authorization/*, the power to grant, with read. Owner has *. 3. Grant the identity Reader on this one resource group, the narrowest role at the narrowest scope that lets it view the group:

RG_ID=$(az group show --name az900-lab11-rg --query id -o tsv)
APP_ID=$(az identity show --name az900-lab11-id --resource-group az900-lab11-rg --query principalId -o tsv)
az role assignment create --assignee-object-id "$APP_ID" --assignee-principal-type ServicePrincipal --role Reader --scope "$RG_ID"

The output joins the three parts of every role assignment: a principal (principalId), a role definition (roleDefinitionName is Reader) and a scope (the group's ID). The group is the scope; it never receives a role itself. 4. Read every assignment that applies to the group, including the ones it inherits:

az role assignment list --resource-group az900-lab11-rg --include-inherited --query '[].{role:roleDefinitionName, principal:principalName, scope:scope}' -o table

Your Reader row has the group's own scope. Your own Owner row (or Contributor, if that is your role) has the subscription's scope: it reaches this group by inheritance, flowing down. In the portal, open the resource group, then Access control (IAM) and the Role assignments tab, to see the same two rows marked This resource and Subscription (Inherited). Change nothing there. The identity has no assignment anywhere else, so everywhere else it is refused: RBAC only allows, and never asks anyone to approve. 5. Open Microsoft Defender for Cloud. In the portal, search for Microsoft Defender for Cloud and open it; the first visit registers it with your subscription, which is free. Read the Secure score on the Overview page and the list on Recommendations. On a new subscription the score can take up to a day to appear, and an empty list is a normal result. Then open Environment settings, then your subscription, and read the Defender plans page without changing it: every paid plan reads Off, and only the free foundational posture management is on. Back in Cloud Shell, count the paid plans:

az security pricing list --query 'length(value[?pricingTier==`"Standard"`])' -o tsv

It prints 0. 6. Map each control to one Zero Trust principle and one defense-in-depth layer, then check the Notes: (a) the Reader assignment you made in step 3; (b) MFA demanded at every sign-in, even from the office; (c) the database subnet's NSG from lesson 8's lab, admitting only the web subnet; (d) a connection string moved from source code into Azure Key Vault; (e) just-in-time VM access opening a management port for one address for an hour; (f) encryption of stored records.