Microsoft AZ-500: Identity and Access Management — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Part of the Microsoft Azure Security Engineer Associate AZ-500 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Identity and Access Management (IAM) in Microsoft Azure is centered on Microsoft Entra ID (formerly Azure AD). It governs who can access which resources, under what conditions, and with what privileges. Effective IAM architecture minimizes standing privilege, enforces conditional and risk-based access, and adopts modern authentication for both humans and workloads while supporting hybrid and external collaboration scenarios.

Microsoft Entra Identity Constructs and Scopes

• Tenants, users, and groups
  • A tenant represents your organization’s identity boundary and trust fabric. Users can be member or guest (B2B) accounts. Use security groups for authorization and Microsoft 365 groups for collaboration features; prefer dynamic groups to reduce manual membership management.
• Administrative Units (AUs)
  • AUs let you delegate directory roles over a subset of users/devices (e.g., regional helpdesk can only manage Europe users). This supports least privilege for directory tasks.
• Directory roles and role assignment scopes
  • Directory roles (e.g., Global Administrator, User Administrator) apply to Microsoft Entra resources. Scope directory roles at an AU when possible to restrict blast radius. The Global Administrator role is required to configure Privileged Identity Management (PIM) initially.
• Azure role-based access control (Azure RBAC) scopes
  • Azure RBAC governs access to Azure resources. Assign roles at management group, subscription, resource group, or resource scope. Inheritance flows downward; always choose the narrowest scope practical to reduce over-privilege.
• Operational reasoning
  • Separate directory roles (Entra) from Azure RBAC (resource authorization). Use AUs and tight RBAC scopes to confine administrative reach, reduce lateral movement opportunities, and simplify access reviews.

Access Control with Azure RBAC and Least Privilege

• Built-in roles and least privilege
  • Prefer the most specific built-in role that fits the task. Example: give container image pull-only access with AcrPull and upload/push access with AcrPush, instead of broad Contributor. For Key Vault, grant administrative control via RBAC only to vault administrators while using granular access policies for specific object operations like certificate management.
• Role-assignment inheritance
  • Assign at the lowest possible scope. Management group or subscription assignments cascade; avoid broad, inherited rights unless deliberate. When you need consistent RBAC across subscriptions, stamp consistent role assignments through Azure Blueprints (or modern IaC alternatives) rather than manual PIM assignment.
• Deny assignments
  • Deny assignments explicitly block actions regardless of allow assignments and are typically created by Azure services such as Azure Policy or Blueprints. Use them to enforce non-negotiable guardrails (e.g., preventing public network rules on sensitive resources).
• Custom roles
  • When built-in roles are too broad, define custom roles with only required actions. Validate through least-privilege testing and access reviews.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Operational reasoning
  • RBAC scoping and custom roles reduce excessive entitlements and audit surface. Deny assignments encode “hard” compliance constraints that cannot be bypassed by mistakenly broad “allow” grants, improving posture resilience.

Privileged Access, Conditional Access, and Identity Protection

• Privileged Identity Management (PIM)

  • Eligible vs active: eligible assignments do not grant standing permissions; users must activate JIT to become active. Enforce approval, justification, and MFA at activation; set limited durations and require ticket references for traceability. Start by discovering privileged roles to understand current exposure. Use periodic access reviews, ideally with resource or group owners as reviewers, to validate continued need.

• Conditional Access (CA)

  • Assignments target users/groups, workload identities, cloud apps, and actions. Conditions include sign-in risk, device platform/state, locations, client apps, and filters for devices and apps. Grant controls can require MFA, compliant or hybrid Azure AD–joined devices, app protection policies, or terms of use. Session controls constrain sign-in frequency, persistent sessions, and app-enforced restrictions (e.g., web-only for SharePoint). Use report-only mode to safely validate policy impact before enforcement. Maintain exclusions for break-glass accounts and phased rollouts to prevent lockouts.

• Identity Protection

  • User risk reflects the likelihood an account is compromised; sign-in risk reflects the likelihood a specific session is risky. Configure policies to require secure remediation:
    • Users with leaked credentials: treat as High user risk; force password reset and block until remediated.
    • Sign-ins from IPs with suspicious activity: treat at least as Medium sign-in risk; challenge with MFA or block for sensitive apps.
  • Integrate with CA to adapt trust in real time. Track risk history and remediation to measure efficacy.

• Operational reasoning

  • PIM eliminates standing privilege and enforces strong, auditable activation. CA and Identity Protection apply zero trust—verifying each access attempt based on user, device, session, and risk—reducing successful credential theft and token replay.

Hybrid and Workload Identities

• Hybrid identity options
  • Password hash synchronization (PHS): syncs password hashes to Entra ID. Simple and resilient; does not enforce on-premises sign-in policies at the time of authentication.
  • Pass-through authentication (PTA): validates passwords against on-prem DCs via lightweight connectors; enforces on-prem password policies and account restrictions in real time, without AD FS.
  • Federation (e.g., AD FS): shifts auth to on-prem STS. Use only when required for complex claims or legacy scenarios; it introduces more servers and operational overhead.
  • Seamless single sign-on (Seamless SSO): signs in users on domain-joined devices inside the corporate network with minimal prompts.
  • Operational choice: to enforce on-prem password policies and account restrictions while minimizing servers, deploy PTA and Seamless SSO and also enable PHS for resiliency/failover of non-PTA-dependent scenarios. Federation alone increases complexity and does not meet the “minimize servers” goal.
• App authentication to Azure SQL from hybrid-joined Windows devices
  • Use Active Directory integrated authentication to minimize prompts and leverage Kerberos/SSO where applicable.
• Managed identities and service principals
  • Managed identities (system-assigned or user-assigned) are first choice for Azure-hosted workloads because they eliminate secrets and rotate credentials automatically. Assign least-privilege RBAC to the identity at the resource scope.
  • Service principals back app registrations; use certificate credentials over client secrets and set the shortest feasible lifetime.
• Workload identity federation
  • Use OIDC federation to let external workload identities (e.g., GitHub Actions, Kubernetes) obtain tokens for Entra apps without storing secrets. Define issuer, subject, and audience claims precisely to constrain who can exchange tokens.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• AKS to ACR access
  • Grant the AKS cluster’s managed identity AcrPull on the target registry using the attach-acr flow, which automates correct scoping and avoids misassignments.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Operational reasoning
  • PTA+PHS+Seamless SSO enforces real-time on-prem controls while maintaining cloud resilience. Managed identities and federation remove static secrets from pipelines and runtime, closing high-frequency credential theft paths.

External Collaboration, Authentication Methods, and App Access

• External identities and B2B collaboration
  • Use B2B guest accounts with cross-tenant access settings, terms of use, and CA targeting guests. Restrict who can invite and prefer just-in-time access through entitlement management.
• Entitlement management and access packages
  • Bundle groups, apps, and SharePoint sites into access packages with policies defining who can request (including external users), approval flows, assignment durations, and access reviews. For reviewer selection, use Group Owners to keep business accountability with resource custodians.
• Authentication methods and passwordless
  • Standardize on strong methods: FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator phone sign-in. Use the combined security info registration (SSPR + MFA) and enforce MFA registration policy for all users. Enable SSPR with on-prem writeback if needed; require secure methods and limit to corporate-managed factors where possible. Disable legacy/basic authentication protocols and block weak SMS-only MFA where risk warrants.
• Microsoft Entra application proxy
  • Publish on-premises web apps without inbound firewall openings. Use connector groups for HA, pre-auth with Entra ID, and layer CA, device compliance, and Identity Protection for zero trust on legacy apps.
• Application registration security
  • Require admin consent workflows; limit who can create apps; classify permissions; prefer application permissions only when no user context is required and scope APIs to the minimum. Disable implicit grant where possible, require assignment for enterprise apps, and prefer certificates over secrets with automated rotation.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

• Operational reasoning
  • Access packages and app proxy provide governed, auditable external access. Strong, passwordless methods raise phishing resistance. Tight app registration controls prevent overbroad consent and reduce the chance of app impersonation.

Practical Problem Scenario

Adobe Inc. needs to grant a third-party vendor temporary administrative access to a subset of Azure resources and publish an internal legacy web app to the vendor, enforcing strong authentication and zero standing privilege.

1. Scope and model access

• Create a resource group rg-vendor-ops and move only required resources into it. Assign the minimum Azure RBAC roles (e.g., Contributor on rg-vendor-ops; Reader on a diagnostics resource group).
• Rationale: Narrow scoping prevents lateral movement. Role inheritance is confined to rg-vendor-ops, containing blast radius.

2. Govern identity and activation with PIM

• Make vendor admins eligible, not permanent, for the required roles; require approval, ticket ID, MFA on activation, and limit activation to 4 hours. Start by running PIM’s Discover privileged roles to baseline existing assignments.
• Rationale: Eligible assignments remove standing privilege. Approval and MFA enforce JIT access aligned to support windows and provide auditable control.

3. Enforce Conditional Access and risk policies

• Create a CA policy targeting the vendor group and the Azure portal and ARM APIs, requiring MFA, compliant/hybrid-joined device, and blocking from risky locations. Enable report-only first; then enforce. Configure Identity Protection: block High user risk (leaked credentials) until password reset; require MFA for Medium sign-in risk (suspicious IP).
• Rationale: CA ties access to device trust and risk in real time. Report-only prevents outages during rollout. Risk policies auto-remediate compromised sessions and accounts.

4. Publish the legacy app with Microsoft Entra application proxy

• Deploy two connectors in separate vendor-exposed subnets for HA. Configure pre-auth with Entra ID, require assignment to the enterprise app, and apply the same CA policy. Use access packages to grant vendor users time-bound access to both the enterprise app and the RG roles; set Group Owners as reviewers.
• Rationale: App proxy eliminates inbound exposure and centralizes auth. Entitlement management standardizes onboarding/offboarding and ensures periodic reviews by resource owners.

5. Secure workload and app credentials

• Replace any client secrets with certificate credentials for service principals; for CI/CD, use workload identity federation instead of storing secrets. For AKS workloads that need images, attach the ACR to the cluster to grant AcrPull to the managed identity.
• Rationale: Removing static secrets closes a common breach vector; federation and managed identities provide least-privilege, auto-rotated access.

6. Protect break-glass and monitor

• Exclude two break-glass accounts from CA but protect them with long random passwords stored offline. Enable access reviews quarterly and export PIM and CA logs to a Log Analytics workspace with alerts on anomalous activations.
• Rationale: Break-glass prevents tenant lockout while being operationally safe. Continuous monitoring detects misuse quickly, maintaining compliance and incident response readiness.

All domains · Network Security Architecture →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →