Azure AZ-104 common mistakes
Azure AZ-104 · Understand the traps and how to avoid them.
Assigning an Entra ID directory role such as Global Administrator when the requirement is to let an administrator manage all resources in a subscription.
Directory roles and Azure RBAC roles look interchangeable in the portal search box, so candidates pick the role whose name sounds most powerful instead of the role that scopes to resources.
What to do instead
Map the requirement to Azure RBAC: Owner for full resource control, Contributor for manage-without-grant, User Access Administrator for role assignments only. Reserve Entra roles (Global Administrator, User Administrator) for directory objects like users, groups, and app registrations.
Designing least privilege by assigning roles on every individual subscription while a management group above them already grants the same or broader access.
Role assignments are inherited and additive; candidates mentally model each subscription as a standalone boundary and forget the tree above it.
What to do instead
Walk the scope hierarchy top-down before answering: list assignments at management group, subscription, resource group, and resource levels, remember that the effective permission set is the union of all of them, and note that narrowing an inherited permission requires a deny assignment (Blueprints/managed apps), not an extra role assignment.
Placing data in the Archive access tier when the scenario says the data may need to be read on short notice, and ignoring early-deletion charges.
Archive looks like the cheapest option, and the tier table is memorized as a price ladder rather than as a state machine with latency and minimum-retention constraints.
What to do instead
Before choosing a tier, check the access requirement against rehydration latency (Standard priority can take up to about 15 hours; High priority is faster and costs more) and against minimum retention before early deletion fees apply (30 days Cool, 90 days Cold, 180 days Archive).
Granting access with a SAS built from the storage account key, or with an ad-hoc service SAS, in a scenario that requires the ability to revoke access for one consumer later.
Portal-generated SAS tokens are quick to create, and candidates do not distinguish a SAS signed by a stored access policy from one signed directly by a key.
What to do instead
If revocation is required, create a stored access policy on the container or share, issue a service SAS that references the policy, and revoke by editing or deleting the policy. Rotating the account key is the only revocation path for account-key-signed SAS and it invalidates every token using that key.
Selecting Stop in the portal for a VM and stating that compute charges stop.
The portal shows the VM as Stopped, which sounds like the same thing as deallocated, and the separate Deallocate action is easy to overlook. Guest-level shutdown inside the OS also leaves the VM allocated.
What to do instead
Only the deallocated state releases the compute allocation and stops compute billing; disks and static public IPs still bill. Recommend auto-shutdown configured to deallocate, or Stop-AzVM (which deallocates) rather than shutdown from inside the guest.
Answering with an availability set when the requirement is a 99.99% SLA or protection against a whole datacenter failing, or sizing a single VM instead of a Virtual Machine Scale Set for autoscaling.
Availability sets and availability zones are both described as 'high availability', and candidates latch onto the first HA construct they learned.
What to do instead
Anchor on the SLA and failure domain: a single VM with Premium SSD is 99.9%, two or more VMs in an availability set is 99.95%, and two or more VMs spread across availability zones is 99.99%. Use zones for datacenter-level failure, availability sets only inside a single datacenter, and VMSS when the scenario mentions scaling or hundreds of identical instances.
Designing a hub-and-spoke topology and assuming spoke VNets can reach each other because each spoke is peered to the hub.
Peering is often drawn as a network cable in diagrams, so candidate assume routed transit that the platform does not provide by default.
What to do instead
State explicitly that VNet peering is non-transitive. To get spoke-to-spoke traffic, deploy an NVA or Azure Firewall in the hub and add user-defined routes on the spoke subnets pointing to it, or use Azure Virtual WAN; enable gateway transit and use remote gateways only for on-premises connectivity sharing.
Adding an outbound NSG rule to allow the return traffic for a permitted inbound connection, or applying the NIC NSG rule before the subnet NSG rule when predicting the outcome.
Candidates carry over a stateful-firewall or ACL mental model from other platforms and do not separate evaluation order from directionality.
What to do instead
Treat NSGs as stateful: a permitted inbound flow automatically allows the reply, so no mirror rule is needed. Evaluate inbound traffic as subnet NSG first, then NIC NSG, and outbound as NIC NSG first, then subnet NSG, with the first deny winning within each NSG.
Planning to query the Activity Log for events older than 90 days, or assuming enabling a diagnostic setting shortens or replaces the built-in retention.
The Activity Log is visible in the portal next to Log Analytics, so it reads like a log store with configurable long-term retention.
What to do instead
The Activity Log keeps 90 days natively and its retention is not user-configurable; to keep events longer, create a diagnostic setting that routes the Activity Log categories to a Log Analytics workspace (retention set on the workspace), a storage account for archive, or an event hub for streaming.
Writing a log-search alert rule when the scenario needs near-real-time notification on a platform metric, or creating an alert rule and forgetting that it does nothing until an action group is attached.
Both alert types live under Azure Monitor > Alerts, and the metric-versus-log distinction plus the alert rule/action group split is easy to miss under time pressure.
What to do instead
Choose metric alerts for platform metrics (evaluated as often as every minute, cheap, no query) and log search alerts for conditions that require a KQL query over a workspace (minimum evaluation frequency of 5 minutes). Always attach an action group, and remember action groups are reusable and can be shared across alert rules.