AZ-500 Manage identity and access: 126 practice questions

12 of the 126 Manage identity and access questions in the Certsqill AZ-500 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-500? Take the free 5-min readiness check →

1. Create one user-assigned managed identity: Which managed identity configuration is most appropriate?

1. Create one user-assigned managed identity, grant it Key Vault Reader on the vault, and assign it to all 50 VMs ✓

   User-assigned managed identities are standalone resources that can be assigned to multiple compute resources. One identity with one RBAC assignment covers all 50 VMs — no per-VM identity management required.
2. Create a service principal with a client secret and distribute the secret to all 50 VMs via Key Vault

   Service principals with client secrets require secret rotation and distribution — managed identities eliminate credential management entirely and are the preferred pattern over service principal secrets.
3. Use a shared Azure AD group containing all 50 VM system-assigned identities and grant the group Key Vault Reader

   While grouping identities reduces RBAC assignments, each VM still needs a system-assigned identity enabled, creating 50 identity objects. User-assigned managed identity achieves the same result with a single identity object shared across all VMs.
4. Enable a system-assigned managed identity on each VM and grant each identity Key Vault Reader individually

   System-assigned identities are tied to the VM lifecycle — enabling 50 system-assigned identities requires 50 separate RBAC assignments, exactly what the question asks to avoid.

User-assigned managed identities can be shared across multiple resources — one identity, one RBAC assignment covers all 50 VMs.

2. Microsoft Entra External ID for B2B collaboration: Which Microsoft Entra feature should be used?

1. Microsoft Entra External ID for B2C — create a B2C tenant where partners self-register with social or local accounts

   B2C is designed for consumer-facing applications where end users self-register with social identities (Google, Facebook) or local accounts. It is not designed for partner enterprise access using existing corporate credentials.
2. Microsoft Entra External ID for B2B collaboration — invite partner users as guest accounts in the company's tenant ✓

   Entra B2B collaboration allows external users from partner organizations to authenticate with their home credentials (federated) and access resources as guest users in the inviting tenant. Invite-only model with no consumer self-registration.
3. Create a separate Azure AD tenant for each partner and establish tenant-to-tenant trust

   Separate tenants per partner is operationally prohibitive. B2B collaboration is specifically designed to federate with partner tenants without creating a separate tenant per partner.
4. Use cross-tenant synchronization to copy partner user objects into the company's tenant

   Cross-tenant synchronization copies user objects between tenants under the same organization — it is not designed for external partner access where partners maintain their own tenants independently.

Entra B2B collaboration enables invite-only partner access using partners' existing corporate credentials — no separate tenant or consumer self-registration required.

3. Create a Conditional Access policy with sign-in risk: Which configuration achieves this?

1. Enable Security Defaults in Entra ID — this automatically blocks all risky sign-ins

   Security Defaults require MFA for all users on every sign-in (not risk-based). They do not implement risk-conditional MFA and cannot be combined with custom Conditional Access policies. Security Defaults are for organizations without licensing for CA.
2. Configure the Entra ID Protection sign-in risk policy (legacy) with remediation set to 'Require MFA' for medium and high risk

   The legacy Entra ID Protection risk policies are deprecated — Microsoft recommends configuring risk-based policies through Conditional Access instead, which provides more granular control over grant controls and session management.
3. Create a Conditional Access policy with sign-in risk condition set to Medium and above, and grant control requiring MFA ✓

   Conditional Access sign-in risk condition evaluates Entra ID Protection real-time risk signals. Setting the condition to 'Medium and above' triggers MFA for risky sign-ins while allowing low-risk users to sign in without additional challenge.
4. Create an Azure Monitor alert rule that fires when Entra ID Protection generates a risk event and triggers an Action Group to send an MFA challenge

   Azure Monitor alert rules cannot intercept live authentication flows to inject MFA challenges. Real-time authentication policy enforcement requires Conditional Access — not post-event monitoring alerts.

Conditional Access with sign-in risk condition ≥ Medium and MFA grant control enforces risk-based MFA without challenging low-risk users.

4. FIDO2 security keys: Which authentication method satisfies phishing resistance requirements?

1. SMS one-time passcode sent to the administrator's phone — delivered over the carrier

   SMS OTP is susceptible to SIM swapping, SS7 interception, and real-time phishing where the victim is prompted to enter the code on a spoofed page. NIST classifies SMS as phishing-susceptible, so it cannot satisfy this requirement.
2. Time-based OTP (TOTP) from an authenticator app — codes that rotate every 30 secs

   TOTP codes are valid for about 30 seconds and can be relayed in real time by a reverse-proxy phishing site — the code is captured and replayed instantly by the attacker's proxy, so TOTP is not phishing-resistant.
3. Microsoft Authenticator push with number matching — the user approves each prompt

   Authenticator push with number matching curbs MFA-fatigue attacks but is not origin-bound, so an attacker-in-the-middle proxy can still relay the approved session. It lacks the origin binding that gives FIDO2 true phishing resistance.
4. FIDO2 security keys (e.g., YubiKey) — hardware-bound, phishing-resistant by design ✓

   FIDO2 security keys use public-key cryptography bound to a specific origin (domain). A phishing site at a different origin cannot intercept or replay the credential — the key will not authenticate to a spoofed site. Portable hardware keys work on shared and personal workstations.

FIDO2 security keys are origin-bound — a phishing site at a different domain cannot intercept or replay the authentication, making them truly phishing-resistant.

5. Eligible assignment with role settings: Which PIM assignment type and settings implement this?

1. Eligible assignment with role settings: require justification, require approval (manager as approver), maximum activation duration 4 hours ✓

   PIM eligible assignments grant the right to activate a role on demand. Role settings enforce justification, approval workflow, and duration limits per activation. The administrator has no standing privilege — they must request and justify each use.
2. Create a custom RBAC role scoped to 4 hours by adding a time-bound role assignment condition that expires the granted access automatically after each use

   Azure RBAC custom roles do not support time-bound conditions or per-use activation workflows; ABAC role assignment conditions target data actions such as storage, not just-in-time role activation. PIM is the correct service.
3. Use Conditional Access session sign-in frequency to force Global Admins to re-authenticate and drop the elevated role after 4 hours of activity

   Conditional Access sign-in frequency only governs how often a user re-authenticates within a session. It cannot gate privileged role activation with justification and approval or cap the activation duration of a role.
4. Create an active assignment with an expiration set 4 hours ahead, then require the admin to renew it manually before each new working session

   An active assignment grants the role standing for its whole lifetime (here 4 hours) with no per-activation justification or approval prompt. A 4-hour expiration does not deliver just-in-time access controls.

PIM eligible assignment with approval, justification, and 4-hour max duration enforces JIT privileged access — the role is not active until explicitly requested and approved.

6. Create a custom RBAC role with actions: Which approach creates this permission set?

1. Assign the built-in Virtual Machine Operator role, which is documented to grant the start, restart, and power-off actions on virtual machines while explicitly withholding the delete and deallocate operations from the assignee

   There is no built-in 'Virtual Machine Operator' role in Azure RBAC. The relevant built-in VM roles are Virtual Machine Contributor, Reader, and a few others — none match start/stop-without-delete, so a custom role is required.
2. Create a custom RBAC role with actions: Microsoft.Compute/virtualMachines/start/action, Microsoft.Compute/virtualMachines/restart/action, Microsoft.Compute/virtualMachines/powerOff/action — and no delete or deallocate actions ✓

   Custom RBAC roles allow specifying exact action strings. Including only start/restart/powerOff and omitting deallocate/delete provides exactly the required permission set. AssignableScopes defines where the role can be assigned.
3. Apply notActions for Microsoft.Compute/virtualMachines/delete/action and Microsoft.Compute/virtualMachines/deallocate/action to the Virtual Machine Contributor built-in role so those two operations are subtracted from its set

   notActions cannot be added to a built-in role to modify it in place. Achieving this requires cloning Contributor's actions into a new custom role minus delete/deallocate — the described in-place edit of the built-in role is not possible.
4. Assign the Virtual Machine Contributor built-in role and layer a customer-authored deny assignment that blocks the delete and deallocate actions on the target virtual machines within the resource group

   Azure deny assignments cannot be created by customers — they are produced only by Azure Blueprints (deprecated) and managed applications. You cannot attach a deny assignment to restrict a built-in role, so this approach is not usable.

Custom RBAC roles specify exact action strings — include only start/restart/powerOff and omit deallocate/delete to achieve the exact permission set needed.

7. Set 'If reviewers don't respond' to 'Remove access': Which setting implements the auto-removal on non-response

1. Use an Azure Automation runbook triggered by a Logic App to remove admin roles on reviewer non-response

   Access reviews include built-in auto-remediation, so a custom runbook is unnecessary complexity. The native 'If reviewers don't respond' setting performs the removal without any external automation.
2. Enable the 'Auto apply results' toggle so the reviewer's chosen decision is applied to the target automatically

   Auto apply results applies whatever decision a reviewer makes (approve or deny). If no one responds there is no decision to apply, so the separate non-response action setting is still required for auto-removal.
3. Set 'If reviewers don't respond' to 'Remove access' in the access review settings ✓

   Entra access reviews allow configuring the action when a reviewer does not respond: No change, Remove access, Approve access, or Take recommendations. Setting 'Remove access' ensures non-responding reviewers result in automatic removal — enforcing least privilege by default.
4. Set the reviewer type to 'System' to auto-deny access when managers don't respond

   Choosing 'System' as reviewer produces recommendations; it does not remove access on non-response. The non-response action is a distinct setting configured independently of the reviewer type.

The 'If reviewers don't respond → Remove access' setting in Entra access review configuration enforces automatic removal when managers fail to review within the review period.

8. Create an IP-based named location for 203.0.113.0/24: Which Conditional Access configuration implements this?

1. Enable Entra ID Protection's location-based risk policy so sign-ins from unfamiliar locations outside the operating regions are blocked, while the corporate office IP range is registered as a familiar trusted location for administrators

   Identity Protection's unfamiliar-location signal feeds risk policies but is not a country allowlist. It flags locations not previously seen for a user rather than enforcing a geographic block on specific countries, so it does not meet the requirement.
2. Configure the Entra tenant's access restrictions so that only US, UK, and Germany remain in the tenant-wide 'Allowed countries' list, automatically blocking every sign-in that geolocates to any other country in the world by default

   There is no tenant-level 'Allowed countries' restriction in Entra ID. Country-based access control is implemented through Conditional Access named locations, not through a tenant-wide setting, so this option describes a feature that does not exist.
3. Use two Conditional Access policies: one requiring MFA from every non-corporate IP address, and a second blocking sign-ins that originate from any of the non-operating countries

   Two separate policies could partially work, but the requirement is that admins on the corporate IP are always allowed, not that they satisfy MFA. The correct design excludes the trusted named location from the country block policy.
4. Create an IP-based named location for 203.0.113.0/24 marked as trusted; create a countries named location excluding US/UK/Germany; create a CA policy blocking sign-ins from that countries location, with the trusted IP location excluded from the policy scope ✓

   Trusted IP named locations are excluded from certain CA conditions. A CA block policy for non-operating countries can exclude the trusted corporate IP range via the 'Exclude' tab under Locations, ensuring office admins are never blocked even if their IP geolocates unexpectedly.

Mark corporate IP as a trusted named location; create a block CA policy for non-operating countries with the trusted IP excluded — ensuring office access is never blocked.

9. Require device to be marked as compliant: Which Conditional Access grant control enforces this?

1. Require device to be marked as compliant ✓

   The 'Require device to be marked as compliant' grant control checks that the device is enrolled in Intune and passes all assigned compliance policies (OS version, encryption, etc.) before granting access. Non-compliant or unmanaged devices are blocked.
2. Require Entra hybrid joined device

   Hybrid Entra join requires the device to be joined to on-premises Active Directory and registered in Entra ID. It does not verify Intune enrollment or compliance policy status — a domain-joined PC can be hybrid joined without meeting any compliance policies.
3. Enable the 'Approved client app' grant control to restrict access to Intune-managed apps

   Approved client app controls which app (e.g., Outlook vs browser) can access the resource — it does not verify device compliance state or Intune enrollment of the underlying device.
4. Require Entra joined device

   Requiring Entra (cloud) join verifies the device is registered in Entra ID but does not check Intune compliance policies. A device can be Entra joined without being enrolled in Intune or meeting compliance requirements.

'Require device to be marked as compliant' verifies Intune enrollment and compliance policy pass — the only grant control that checks both enrollment and compliance state.

10. In the Enterprise Applications blade for the application's: Where should these configurations be made?

1. In the App Registrations blade under the application's manifest and appRoles section

   The app registration manifest defines technical properties such as appRoles, OAuth2 permission scopes, and redirect URIs — not user assignment or SCIM provisioning. Those are configured on the enterprise application object instead.
2. In the Enterprise Applications blade for the application's service principal object ✓

   App registration creates the application definition (client ID, secrets, API permissions). The Enterprise Application (service principal) is the instance in the tenant where user assignment, provisioning, SSO, and app-level permissions are configured.
3. In the API Permissions section of the App Registration for delegated scopes

   API Permissions in the app registration define which Microsoft Graph or other API scopes the app requests. They do not control which users can access the app or how provisioning is set up.
4. Under Entra ID, Users, then App Assignments configured individually per user account

   There is no per-user App Assignments blade under Users in Entra ID. User-to-app assignment is configured centrally on the Enterprise Application object, not one user at a time in the Users blade.

Enterprise Applications (service principal) is where user assignment, SCIM provisioning, SSO configuration, and app access policies are managed — separate from the app registration's technical definition.

11. Configure workload identity federation on the Entra app: Which approach removes the need for stored credential

1. Use a user-assigned managed identity and attach it to the GitHub Actions runner so it obtains Azure tokens without a stored secret

   Managed identities require the compute running the workload to be an Azure resource. GitHub-hosted runners run on GitHub's infrastructure, so a managed identity cannot be attached to them (only to self-hosted runners on Azure VMs).
2. Store the service principal certificate (PFX) as a GitHub secret in place of the client secret and authenticate the deployment with the private key

   Replacing a client secret with a certificate still keeps a credential — the private key — stored in GitHub secrets. Workload identity federation eliminates stored credentials entirely because the OIDC token is ephemeral and issued per run.
3. Configure workload identity federation on the Entra app registration with a federated credential for the GitHub Actions OIDC provider and repository ✓

   Workload identity federation allows GitHub Actions to exchange a GitHub-issued OIDC token for an Entra access token without any stored secrets. The Entra app registration trusts GitHub's OIDC issuer for a specific repository/branch — no client secret or certificate needed.
4. Rotate the service principal client secret every 30 days from Azure Key Vault and sync the new value into GitHub secrets automatically each cycle

   Automatic rotation shortens secret exposure time but does not eliminate stored secrets; a valid secret still lives in GitHub during each period. Workload identity federation is the true zero-secret approach.

Workload identity federation trusts GitHub's OIDC provider — GitHub Actions exchanges an ephemeral OIDC token for an Entra access token with zero stored secrets.

12. The Conditional Access What If tool: Which tool provides this simulation?

1. The Entra ID Protection risk investigation dashboard, which surfaces historical user and sign-in risk detections for administrators to review

   The Identity Protection risk dashboard shows historical risk events and user/sign-in risk levels. It is not a policy simulation tool and cannot evaluate which Conditional Access policies would apply to a hypothetical sign-in.
2. The Entra sign-in logs filtered by user and application to see which policies were applied during past authentications

   Sign-in logs show which CA policies applied to real, historical sign-ins and therefore require an actual authentication to have occurred. The What If tool simulates a future hypothetical sign-in with no real authentication.
3. The Azure Monitor alert rule preview, which evaluates Conditional Access policy events against collected diagnostic log data for the tenant

   Azure Monitor alert rules evaluate conditions against log data that already exists. They do not simulate Conditional Access policy evaluation for a hypothetical, not-yet-occurred sign-in scenario.
4. The Conditional Access What If tool — simulates which policies apply for specified user, app, IP/location, device, and sign-in risk inputs ✓

   The CA What If tool allows administrators to simulate a sign-in scenario with specific inputs (user, application, IP address, device, risk level) and shows exactly which CA policies would apply and what their outcomes would be — without affecting real users.

The CA What If tool simulates policy evaluation for a hypothetical sign-in without requiring a real sign-in event — enabling pre-deployment policy verification.

Other AZ-500 domains

• Manage security operations — 137 questions →
• Secure compute, storage, and databases — 132 questions →
• Secure networking — 105 questions →
• All 500 AZ-500 questions →