Skip to content

AZ-305 · Identity and Governance

Exam domain: 25–30%

Every AZ-305 question in this domain reduces to one of four decisions:

  1. Where does identity live?
  2. What’s the tenant boundary?
  3. Who can do what, where?
  4. How is that enforced automatically?

Entra ID — the tenant is the identity boundary

Section titled “Entra ID — the tenant is the identity boundary”

Tenant vs subscription

A tenant = an Entra ID directory. It’s the identity plane. A subscription = a billing container inside a tenant. It’s the resource plane. One tenant → many subscriptions. You cannot move a user across tenants, but you can move a subscription.

ScenarioRecommended topology
Single company, single directorySingle tenant, many subscriptions
M&A / distinct security posturesMulti-tenant, connected via Entra B2B
Customer-facing app with sign-upSeparate Entra External ID (formerly B2C) tenant
Hybrid AD (on-prem + cloud)Entra Connect (cloud sync) → single Entra tenant

Management groups nest above subscriptions. They exist so you can apply RBAC and Azure Policy to many subscriptions at once.

flowchart TD
  R[Tenant Root Group] --> P[Platform]
  R --> L[Landing Zones]
  R --> D[Decommissioned]
  P --> ID[Identity sub]
  P --> Net[Connectivity sub]
  P --> Mgmt[Management sub]
  L --> Corp[Corp workloads]
  L --> Online[Online workloads]
  L --> Sandbox[Sandbox]
  • Depth ≤ 6 levels. Anything deeper is a smell.
  • Do not create one MG per environment (dev/test/prod). Instead, tag subscriptions and let Policy target tags.
  • Every subscription belongs to exactly one MG.

Azure RBAC is expressed as assignments of (role) × (scope) × (principal).

  1. Role — collection of Actions (allowed) and NotActions (subtracted). Prefer built-in.
  2. Scope — MG > Subscription > Resource group > Resource. Assignments inherit downwards.
  3. Principal — user, group, service principal, or managed identity.
custom-role.json
{
"Name": "Read-only KeyVault Secrets Peeker",
"IsCustom": true,
"Description": "See secret names in Key Vault, but not values.",
"Actions": [
"Microsoft.KeyVault/vaults/read",
"Microsoft.KeyVault/vaults/secrets/read"
],
"NotActions": [],
"DataActions": [],
"AssignableScopes": [
"/subscriptions/00000000-0000-0000-0000-000000000000"
]
}

Azure Policy — enforcement without gates

Section titled “Azure Policy — enforcement without gates”

Effect matters

  • Deny — blocks non-compliant resources at create time.
  • DeployIfNotExists (DINE) — creates missing resources (e.g. deploy a diagnostic setting).
  • Modify — mutates the request (add tag, force a SKU).
  • AuditIfNotExists — reports, doesn’t block. Good for rollouts.
  1. Author policy at Audit effect and assign at MG scope.
  2. Watch non-compliance for 1–2 weeks.
  3. Fix your worst offenders.
  4. Flip to Deny / DeployIfNotExists.
deny-public-ip-vm.json
{
"policyRule": {
"if": {
"allOf": [
{ "field": "type", "equals": "Microsoft.Network/networkInterfaces" },
{
"field": "Microsoft.Network/networkInterfaces/ipConfigurations[*].publicIPAddress.id",
"exists": "true"
}
]
},
"then": {
"effect": "deny"
}
}
}
RequirementAnswer
”Contractors should have admin for 8 hoursEntra PIM with time-bound activation
”Block subscriptions from moving out of an MG”Resource lock at MG scope
”All storage accounts must have HTTPS-only”Azure Policy Deny at MG
”Non-prod should be cheaper skus”Azure Policy Modify on sku.name
”Least-priv for a CI pipeline in AKS”Workload identity (federated)