The AZ-104 is not a memorisation exam. It’s a reasoning exam. Most candidates who fail don’t fail because they didn’t study — they fail because the exam tests edge cases, exceptions, and interactions between services that documentation explains individually but never shows you together.
These are the five topics that consistently expose that gap.
1. Management-Plane vs Data-Plane RBAC (Domain 01)
This is the single most tested distinction in the identity and governance
domain, and it’s the one that feels obvious until the exam puts it in a
scenario.
Here’s the trap: a user has the Storage Account Contributor role. Can
they read blob data from the storage account?
No. Storage Account Contributor is a management-plane role — it lets
you manage the storage account itself (configure settings, view keys,
manage network rules). It does not grant access to the data inside it.
To read blob data, you need a data-plane role: Storage Blob Data Reader
or Storage Blob Data Contributor.
Now the second trap: a user has the storage account’s access key. What
can they access?
Everything. Account key access bypasses RBAC entirely. A user with an
access key can read any content in the account regardless of what roles
they hold — or don’t hold.
The exam also tests the reverse: a user with a data-plane role but no
management-plane role tries to access blob data through the Azure portal.
This can fail even with the correct data-plane role because the portal
itself requires management-plane permissions to render the storage account
UI. Both layers are sometimes required depending on the access path.
📖 Every RBAC sub-topic and exact question type mapped out:
AZ-104 Domain 01 — Identities and Governance
2. VNet Peering Is Not Transitive (Domain 04)
Networking is widely considered the hardest domain on the AZ-104, and
VNet peering transitivity is the most reliably tested gotcha within it.
The setup: VNet A is peered with VNet B. VNet B is peered with VNet C.
Can VNet A reach VNet C?
No. VNet peering is not transitive by default. Each peering is a
direct, bilateral connection. VNet A can reach VNet B. VNet B can reach
VNet C. VNet A cannot reach VNet C through VNet B — even though a path
exists in the diagram.
To enable A-to-C connectivity, you need either a direct peering between A
and C, or a hub-and-spoke topology with a VPN Gateway or Azure Firewall
acting as the transit point with the “Use Remote Gateways” option enabled.
The exam also tests what happens when two VNets have overlapping address
spaces — you cannot peer them until the overlap is resolved. One VNet’s
address space must be modified first. And cross-tenant peering has
additional prerequisites that same-tenant peering does not require.
📖 Full VNet peering, NSG, DNS, and Bastion breakdown:
AZ-104 Domain 04 — Networking
3. SAS Token Types When Account Key Access Is Disabled (Domain 02)
There are three SAS token types on the AZ-104 and they are not
interchangeable. The exam specifically tests what happens when account key
access is disabled on a storage account — and most candidates don’t know
which tokens survive that change.
Here’s the breakdown:
-
User delegation SAS — backed by Entra ID (Azure AD) credentials.
Works even when account key access is disabled. -
Service SAS — signed with the account key. Blocked when account key
access is disabled. -
Account SAS — also signed with the account key. Also blocked when
account key access is disabled.
So if the exam tells you a storage account has account key access disabled
and asks which SAS type to use — the answer is always user delegation SAS.
There’s a second layer to this: the effective permissions a user gets
through a SAS are the intersection of their RBAC role permissions and
the SAS-defined permissions. The SAS cannot elevate access beyond what the
user’s role already allows. The exam tests both of these behaviours
separately and sometimes together in the same scenario.
📖 Full storage access mechanism breakdown including SAS, access keys,
and identity-based access:
AZ-104 Domain 02 — Storage
4. VMSS Autoscale Instance Count Calculation (Domain 03)
Domain 03 is the broadest domain on the exam — ARM templates, containers,
App Services, virtual machines. But the topic that causes the most
unexpected point loss is VMSS autoscale calculation, because it requires
arithmetic, not just knowledge.
The exam gives you a scenario like this:
- Starting instance count: 2
- Scale-out rule: if CPU > 70% for 5 minutes, add 2 instances
- Scale-in rule: if CPU < 30% for 5 minutes, remove 1 instance
- Cooldown period: 10 minutes
- Minimum instances: 2, Maximum: 8
Then it describes a CPU usage sequence over 30 minutes and asks: how many
instances are running at the end?
The trap is the cooldown period. After a scale event fires, no further
scale events can occur until the cooldown window has elapsed — even if the
CPU threshold is still being exceeded. Candidates who ignore the cooldown
end up with the wrong instance count.
You need to trace each 5-minute window, check whether the CPU threshold
is met, check whether the cooldown has expired since the last event, apply
the rule if both conditions are true, and track the running count against
the minimum and maximum limits throughout.
The only way to get comfortable with this is to practise it with actual
questions before exam day.
📖 Full compute domain breakdown including VMSS, availability sets,
containers, and App Service:
AZ-104 Domain 03 — Compute
5. Azure Budgets Don’t Stop Anything (Domain 01)
This one is short but it costs marks every sitting.
Azure Budgets let you set a spend threshold and configure alerts for when
costs approach or exceed that threshold. Most candidates assume a budget
acts as a spend cap — that once you hit the limit, Azure stops or
deallocates resources to prevent further charges.
It doesn’t. A Budget threshold triggers a notification. That’s it.
Resources continue running. New deployments continue succeeding. Your bill
continues growing. The Budget is purely an alerting mechanism.
The exam tests this directly — given a Budget with defined thresholds and
an action group, you need to determine what happens when costs reach those
thresholds. The correct answer is always: a notification is sent, nothing
else changes.
If you actually want to enforce a spend limit programmatically, you need
Azure Policy or automation runbooks — Budgets alone will not do it.
📖 Full governance domain coverage including Azure Policy, resource
locks, a