Azure AZ-500 common mistakes
Azure AZ-500 · Understand the traps and how to avoid them.
Selecting a directory role (for example Global Administrator or User Administrator) when the scenario asks for granting a team the ability to manage Azure resources such as VMs and storage accounts - or, in reverse, selecting Owner or Contributor to let someone create and manage users and groups in Microsoft Entra ID.
Candidates collapse 'admin' into one concept and treat Owner as a super-role. Owner/Contributor are Azure RBAC roles scoped to resources, subscriptions, or management groups and grant no directory permissions; Global Administrator grants no access to Azure resource data by default (it must be elevated in the portal, and the elevation is time-limited and audited).
What to do instead
Before answering, classify the object being managed: directory objects (users, groups, app registrations, Conditional Access) map to Microsoft Entra ID roles; Azure resources map to Azure RBAC role definitions at a scope (management group, subscription, resource group, resource). If the requirement is 'least privilege directory admin', answer with the specific Entra role (for example User Administrator, Application Administrator, Privileged Role Administrator) rather than Global Administrator, and remember Global Administrator can elevate but that is not a design pattern.
Concluding that a user will be blocked (or that a requirement is already satisfied) because a Conditional Access policy exists, without checking the policy State - the policy is actually in Report-only mode, or the user/group/app is outside the policy's assignments, or the client app condition excludes the very client being tested (for example 'Exchange ActiveSync' or 'Other clients' left unselected).
Policies look identical in the blade regardless of state, and report-only policies still show up in sign-in logs as 'report-only: not applied'. Candidates read the policy name and assume enforcement, and they forget that Conditional Access is allow-by-default: if no policy targets the sign-in, access is granted.
What to do instead
For every Conditional Access scenario, evaluate four things explicitly: State (On vs Report-only vs Off), the assignment set (users/groups, cloud apps, and - for the user case - client apps and platforms), the conditions (sign-in risk, location, device state), and the grant controls (block vs require MFA/compliant device). If any one of these does not cover the principal or client in the question, the policy does not apply.
Designing a solution around Privileged Identity Management (eligible, time-bound, approval-required role activation), Conditional Access risk-based policies, or Identity Protection risk detections for a tenant whose stated licensing is Microsoft Entra ID Free or P1 only.
These features are gated on Microsoft Entra ID P2 (PIM, Identity Protection risk policies, access reviews for some scenarios). Candidates focus on the security control and skip the licensing line in the scenario, so they pick a correct-sounding but unavailable control.
What to do instead
Scan the stem for licensing before choosing identity controls. Free: security defaults, basic MFA, no Conditional Access. P1: Conditional Access, group-based licensing, hybrid join, self-service password reset for cloud. P2: PIM, Identity Protection risk policies, access reviews, entitlement management. If the tenant is P1 and the requirement is just-in-time privileged access, answer with a P1-compatible control (for example Conditional Access with authentication strength or a manual process) and note the licence gap, rather than asserting PIM.
Choosing a virtual network service endpoint when the requirement is that a storage account or SQL database be reachable from on-premises or from a peered/other-region VNet without transiting the public internet - or when the requirement is to restrict access to a single private IP inside the VNet.
Service endpoints and private endpoints are both described as 'restricting PaaS to the VNet', so candidates treat them as interchangeable. Service endpoints only extend the VNet identity to the PaaS service over the Azure backbone; the service still resolves to its public IP, traffic from on-premises sources is not covered, and the PaaS firewall must still allow the subnet.
What to do instead
Map the requirement to the mechanism: 'PaaS must be reachable from on-premises / from another VNet / from a specific private IP with no public exposure' -> Private Endpoint plus Private DNS zone. 'Restrict a PaaS firewall to my own subnet, same region, no on-prem access needed' -> Service Endpoint. 'Deny all public network access entirely' -> Private Endpoint plus set the public network access property to Disabled.
Filtering traffic by domain name (FQDN) in a network security group, or attempting to allow/deny specific internet FQDNs such as *.windowsupdate.com in an NSG rule, instead of using Azure Firewall application rules or a service tag.
NSGs and Azure Firewall both appear in the 'control outbound traffic' objective, and the NSG rule blade offers a Destination field that looks like it accepts hostnames. NSG rules are 5-tuple (source/destination IP, port, protocol) evaluated at layer 3/4 only; they cannot inspect the HTTP Host header or TLS SNI.
What to do instead
If the requirement names specific FQDNs, answer with Azure Firewall (application rules for HTTP/HTTPS; network rules for non-HTTP with IPs) or a firewall policy, optionally combined with NSGs at the subnet level. If only Azure service endpoints are needed, use NSG service tags. Use NSGs for IP/port-based segmentation between subnets and tiers, never for name-based egress control.
Attaching a network security group to AzureBastionSubnet with the default deny-inbound rules, or assuming a custom NSG can be applied to AzureBastionSubnet without the required Bastion rules (inbound 443 from Internet and from GatewayManager, 8080/5701 from GatewayManager/VirtualNetwork, outbound 443 to AzureCloud and 22/3389 to VirtualNetwork).
Candidates apply the standard 'deny all inbound, allow only from the corporate range' pattern uniformly to every subnet. Azure Bastion has a fixed, documented rule set and will fail to deploy or function without it, because the service requires inbound 443 from the Internet by design.
What to do instead
Treat AzureBastionSubnet as a special case: the subnet must be named exactly AzureBastionSubnet, be at least /26 (or /27 for the developer SKU), and any NSG attached must contain the Bastion-required rules. If a scenario requires that nothing on the internet reach the VNet, the answer is to use Bastion with the mandated rules plus restrictive rules on workload subnets - not to deny 443 on the Bastion subnet.
Assuming that regenerating a storage account access key revokes all existing SAS tokens, or assuming that rotating keys does invalidate a user delegation SAS - and equally, assuming that deleting a stored access policy is unnecessary because a SAS will expire on its own.
Key rotation and SAS revocation are taught together, so candidates over-generalise. Regenerating the account key invalidates SAS tokens signed with that key, but a user delegation SAS is signed with a Microsoft Entra ID credential and survives key rotation; SAS issued from a stored access policy can be revoked by modifying or deleting the policy or by revoking the delegation key.
What to do instead
State which credential signed the SAS. Account-key-signed SAS: control via stored access policy (preferred) or key rotation. User delegation SAS: revoke by revoking the user delegation key (Revoke user delegation keys) or by deleting/altering the stored access policy. For 'immediate revocation of all delegated access without breaking applications that use account keys', the answer is revoke delegation keys, not regenerate keys.
Selecting Transparent Data Encryption with a customer-managed key when the requirement is that database administrators or anyone with database-level access must be unable to read sensitive column values, or selecting Always Encrypted when the requirement is only to encrypt the database, backups, and logs at rest.
All three 'encryption' features sit in the same SQL security blade and all mention keys, so the distinction between encryption at rest (TDE), client-side encryption where the key never reaches the server (Always Encrypted), and masking (Dynamic Data Masking, which is not encryption) gets lost.
What to do instead
Match the threat model to the feature. Protect data and backups at rest, with the server able to read data normally, and optionally bring your own key to Key Vault -> TDE with customer-managed key. Protect specific columns from privileged users including sysadmins/DBAs, with encryption and decryption happening in the client driver -> Always Encrypted (key in Key Vault or Windows certificate store). Only reduce accidental exposure in query output for non-privileged users, with no cryptographic protection -> Dynamic Data Masking. Note that Always Encrypted requires connection-string changes and supported driver versions.
Answering that enabling the secure score in Microsoft Defender for Cloud (or raising the score) is what enforces a configuration such as 'TLS 1.2 minimum on all storage accounts' or 'MFA required for subscription owners' - or treating the regulatory compliance dashboard as the enforcement mechanism.
Defender for Cloud surfaces the same recommendations that Azure Policy produces, so the two look like one product in the portal. Recommendations and secure score are assessment and reporting; enforcement comes from the underlying Azure Policy definitions/initiatives (the Microsoft cloud security benchmark initiative) and from the Defender plan that provides the detection.
What to do instead
Separate the three layers: Azure Policy (definition/initiative assigned at management group or subscription, with Deny or DeployIfNotExists effect) enforces and remediates configuration; Defender for Cloud assesses against that policy and reports recommendations and secure score; Defender plans (for example Defender for Servers Plan 2, Defender for Storage) add threat detection and advanced features. If the question says 'prevent' or 'enforce', answer Azure Policy; if it says 'identify', 'score', or 'report', answer Defender for Cloud.
Assuming that connecting a data source in Microsoft Sentinel is sufficient to produce incidents, or conflating an analytics rule with an automation rule - for example proposing an automation rule to create incidents, or an analytics rule to run a playbook that blocks an IP after an incident is created.
The Sentinel workflow (connector -> analytics rule -> incident -> automation rule -> playbook) is presented as a single pipeline, and both 'rules' live in the same Configuration section of the portal. Candidates also forget that many connectors only ingest raw logs and some (for example the Microsoft Defender XDR connector) can create incidents from the source product instead.
What to do instead
State the pipeline explicitly in the answer: a data connector ingests logs into the Log Analytics workspace; an analytics rule (scheduled, NRT, Microsoft security, fusion) evaluates those logs and creates alerts/incidents; an automation rule triggers on incident creation/update and can run a playbook (Logic App) that performs the response action. If the requirement is 'create an incident when X is observed', the missing component is the analytics rule; if the requirement is 'notify the SOC / disable the account when an incident is created', the missing component is the automation rule plus playbook.