DEV Community: CrackCerts

How I'd Structure 4 Weeks of AZ-104 Study (Domain-by-Domain Plan)

CrackCerts — Tue, 31 Mar 2026 15:13:44 +0000

The AZ-104 covers five domains across identity, storage, compute,
networking, and monitoring. That's a lot of ground — and most study plans
either treat every topic equally (wrong) or follow someone else's timeline
that doesn't reflect how the exam actually weights things.

This plan is built around the official domain weightings. The domains
worth the most marks get the most time. The sequencing follows a logical
dependency order — each week builds on the one before it.

Assumptions: roughly 1–2 hours of study per day, 5 days a week. If you
have more time, compress the plan. If you're starting from scratch with
no Azure experience, add an extra week before Week 1 to get hands-on
with the Azure portal basics.

Before You Start: Understand the Exam Format

The AZ-104 is not a recall exam. It's a scenario-based reasoning exam.

Questions don't ask you to define services — they put you inside a
real-world configuration and ask what you would do, what is blocked,
what happens next, or what the correct sequence of steps is.

That means hands-on practice in a real Azure environment is not optional.
A free Azure trial gives you enough to work through the configurations
that appear most on the exam. Use it throughout this plan.

Exam structure to keep in mind:

50–55 questions across two sections
100 minutes of actual exam time
Passing score: 700 out of 1000 (scaled scoring)
9 question formats including case studies, drag-and-drop, Yes/No series, and dropdown completion
Once you move to Section 2, you cannot return to Section 1

📖 Full exam format breakdown including all 9 question types with
examples: AZ-104 Exam Guide

Week 1 — Domain 01: Identities and Governance (20–25%)

Start here. Identity and governance is jointly the highest-weighted domain
alongside compute, and it establishes the access control model that
underpins every other domain. Understanding RBAC scope inheritance before
you study networking or storage makes both significantly easier.

What to cover this week:

Microsoft Entra ID (formerly Azure Active Directory)

Creating users and groups, including dynamic membership rules
How dynamic group rules evaluate user attributes (department, country, logical operators)
Managing licenses through group assignment — including nested group inheritance and which group types are valid license targets
Configuring SSPR — which identity types it applies to, which admin roles can configure it, which group types can scope it
Managing B2B guest users and external collaboration settings

Azure RBAC

Built-in roles and their scope: Owner, Contributor, Reader, User Access Administrator
The critical distinction: management-plane roles vs data-plane roles
Assigning roles at management group, subscription, resource group, and resource scope — and how assignments inherit downward
Custom role definitions: actions, notActions, dataActions, notDataActions
Deployment stacks and DenyDelete — how this overrides even Owner-level RBAC

Azure Policy

Policy effects: append, deny, audit, modify
Append policies apply to new resources only — not retroactive
How conflicting policies interact across management group scopes
Tag policy scenarios — what gets appended, what doesn't, what is inherited

Resource Locks and Subscriptions

CanNotDelete vs ReadOnly lock types
Which scopes support locks (resource, resource group, subscription — not management groups)
Azure Budgets: notification-only, they do not stop resources
Subscription quota limits and how VM family quotas work

Hands-on this week: Assign RBAC roles at different scopes in the
portal. Create a dynamic group with a membership rule. Create an Azure
Policy and observe which resources it affects. Apply a resource lock and
try to delete the resource.

📖 Every sub-topic in Domain 01 mapped to exact question types:
AZ-104 Domain 01 — Identities and Governance

Week 2 — Domain 02: Storage (15–20%)

Storage is the most detail-oriented domain on the exam. Questions test
specific settings, exact JSON rule syntax, and edge-case behaviour of
access mechanisms. The topics are narrower than identity or networking
but they require precision.

What to cover this week:

Storage Account Fundamentals

Account types: BlobStorage, BlockBlobStorage, StorageV2 (GPv2) — and which services each supports
Redundancy options: LRS, ZRS, GRS, GZRS, RA-GRS, RA-GZRS — what each protects against and where data is replicated
Which settings are immutable after account creation (performance tier, infrastructure encryption)
Network routing: Microsoft global network vs internet routing

Access Control

The three SAS types: user delegation SAS, service SAS, account SAS
Which SAS types work when account key access is disabled (user delegation only)
Effective SAS permissions = intersection of RBAC role + SAS permissions
Stored access policies: hard limit of 5 per container
Identity-based access for Azure Files: prerequisite configuration before IAM role assignments take effect

Blob Storage

Access tiers: Hot, Cool, Archive — costs, minimum durations, and rehydration requirements
Lifecycle management rules: JSON structure, condition properties, action properties, prefix scoping
When two lifecycle rules apply to the same blob: more restrictive action wins
Soft delete (protects against deletion) vs versioning (protects against overwrites)
Object replication prerequisites: which account types are supported

Azure Files

Storage account types that support file shares
SMB port 445 — must be open for external access
UNC path format for scripting access to a file share

Hands-on this week: Create a storage account with different redundancy
options. Generate each SAS token type and test access. Disable account
key access and observe which tokens still work. Write a lifecycle
management rule in JSON and apply it to a container.

📖 Every sub-topic in Domain 02 mapped to exact question types:
AZ-104 Domain 02 — Storage

Week 3 — Domain 03: Compute (20–25%)

Compute is the broadest domain on the exam — 19 sub-topics spanning
ARM templates, virtual machines, containers, and App Services.
The breadth is the challenge here more than the depth of any single topic.

What to cover this week:

ARM Templates and Bicep

Reading Bicep files: hardcoded vs parameter-driven values, declarative nature, idempotency
Copy loops with copyIndex() — how to calculate resource names and count from a template
Deployment modes: incremental vs complete (complete removes pre-existing resources)
PowerShell cmdlets by deployment scope: New-AzResourceGroupDeployment vs New-AzSubscriptionDeployment
Where to find deployment history for a past deployment

Virtual Machines

VM state requirements: which operations require a running VM vs stopped/deallocated
Disk types and host caching: Premium vs Standard, LRS vs ZRS, caching trade-offs
Azure Disk Encryption vs encryption at host vs customer-managed keys — what each protects and where the key is held
Moving a VM: cross-subscription move constraints, which associated resources can and cannot move

Availability and Scale

Availability sets: fault domains (hardware failure) vs update domains (planned maintenance)
Calculating maximum VMs simultaneously unavailable given fault domain and update domain counts
VMSS autoscale: instance count calculation respecting cooldown periods, minimum, and maximum limits

Containers

Container Registry tiers: which features require Premium (geo-replication, private endpoints, ACR Tasks)
Container Instances: OS constraints for container groups, file share mounting eligibility, restart policy
Container Apps: managed identity for Key Vault access, minimum subnet size for custom VNet (/27)
Which container services support autoscaling

App Service

Plan OS constraint: Windows vs Linux runtime stack eligibility
Minimum plan count when multiple apps have different runtime requirements
Tier requirements: deployment slots (Standard+), rule-based scale-out (Standard+), zone redundancy (Premium+)
VNet integration vs Hybrid Connections for on-premises connectivity
Deployment slots: slot swap rollback, backup configuration applies per slot not per app

Hands-on this week: Deploy a Bicep file and redeploy it — observe
idempotency. Create an availability set with specific fault and update
domain counts. Configure a VMSS with autoscale rules and manually trigger
scale events. Create an App Service plan and add a deployment slot.

📖 Every sub-topic in Domain 03 mapped to exact question types:
AZ-104 Domain 03 — Compute

Week 4 — Domain 04 + Domain 05: Networking and Monitoring (25–35% combined)

The final week covers two domains. Domain 04 (networking) is widely
considered the hardest domain on the exam despite its 15–20% weighting
— questions require multi-step reasoning through peering, routes, NSG
rules, and DNS simultaneously. Domain 05 (monitoring) is the smallest
domain at 10–15% and is more straightforward once you understand the
vault distinction.

Split the week roughly 60/40 in favour of networking.

Domain 04 — Networking

VNets and Peering

VNet peering is not transitive: A↔B, B↔C does not give A access to C
Overlapping address spaces cannot be peered
Cross-tenant peering requires additional prerequisites
Disconnected peering status: how to resolve it
DNS resolution across peered VNets: which VNet must be linked to the private DNS zone

NSGs

NSG regional constraint: can only be associated with subnets in the same region
Evaluating effective rules: subnet-level NSG + NIC-level NSG combined effect on the same VM
Service tags for outbound PaaS access (e.g. Storage, AzureActiveDirectory)
NSG on subnet does not control inbound traffic to a VNet-integrated App Service

Routing and Connectivity

User-defined routes: next hop types, subnet association
Network Watcher tools: IP flow verify vs Connection troubleshoot — which tool for which diagnostic task
Private endpoint vs service endpoint: private IP in your VNet vs optimised routing
Azure Bastion SKUs: Basic (browser only) vs Standard (native client), one-hop peering limit, /26 minimum subnet

Load Balancers and DNS

Standard LB: Standard SKU public IPs only, NSG required on VMs, IPv6 not supported as frontend
Basic LB: VMs must be in the same availability set or scale set
Private DNS zone auto-registration: which VMs get records, which IP type is recorded
DNS resolution precedence: NIC-level overrides VNet-level

Domain 05 — Monitoring and Maintenance

Azure Monitor and Alerts

Alert rules target the Log Analytics workspace for event log alerts, not the VM itself
Activity log alert scope: operations on a resource trigger both resource-scoped and RG-scoped alerts; operations on the RG only trigger the RG-scoped alert
Alert suppression: prevents notifications, alert still fires and appears in portal
Minimum alert rules and action groups: each unique signal needs its own rule; multiple alerts to the same recipients can share one action group

Azure Backup

Recovery Services vault: Azure VMs, Azure Files, SQL in Azure VMs, on-premises workloads
Backup vault: Azure Managed Disks, Azure Database for PostgreSQL, Azure Blobs at account level
Blob containers: protected by neither vault — use soft delete or versioning
Backup policy compatibility: not all policy types support VMs with Azure Disk Encryption or Trusted Launch enabled
Site Recovery test failover: subnet name matching between source and target VNets

Hands-on this week: Create two VNets, peer them, and verify
non-transitive behaviour with a third VNet. Build an NSG with priority-
ordered rules and test effective access. Deploy Azure Bastion and connect
to a VM. Create a Recovery Services vault, configure a backup policy,
and perform a test restore.

📖 Full Domain 04 breakdown:
AZ-104 Domain 04 — Networking

📖 Full Domain 05 breakdown:
AZ-104 Domain 05 — Monitor and Maintain

The Week Before the Exam

Stop introducing new material. This week is entirely for consolidation
and timed practice.

Take at least two full-length practice tests under real exam conditions
— 100 minutes, no pausing, no looking things up mid-test. Review every
wrong answer with its explanation. The goal isn't just to see what you
got wrong; it's to understand why the correct answer is correct and why
the distractor options are wrong.

Pay particular attention to questions where you got the right answer
for the wrong reason — those are the ones that will cost you on exam day
when the scenario is framed slightly differently.

📖 Full exam overview including all question types and what to expect
on exam day: AZ-104 Exam Guide

→ AZ-104 Practice Tests on CrackCerts —
full-length, timed, with detailed explanations for every question.

→ AZ-104 Last Minute Cheat Sheet

AZ-104 Last-Minute Cheat Sheet: The Rules, Limits, and Traps That Actually Show Up

CrackCerts — Tue, 31 Mar 2026 14:38:45 +0000

You've studied the domains. You've done the labs. Now it's 48 hours before
your AZ-104 exam and you need one place with the rules that actually trip
people up — not another overview of what the exam covers.

This is that page.

Everything below is pulled from what the exam actually tests. Bookmark it,
read it the morning of your exam, and don't let any of these cost you marks.

Exam Format — Know This Before You Start

Questions: 50–55 total
Time: 100 minutes of actual exam time (timer starts when you click "Start Exam," not before)
Passing score: 700 out of 1000 (scaled — this is not 70% correct)
Sections: Two sections. Section 1 has ~45–51 questions including one case study. Section 2 has 4–6 scenario-based questions.
Critical: Once you move to Section 2, you cannot go back to Section 1. Review everything in Section 1 before proceeding.
Result: Shown immediately on screen — Pass or Fail, your score, and a domain-by-domain breakdown.

Domain 01 — Identity and Governance (20–25%)

RBAC scope inheritance flows downward. A role assigned at a management group applies to all child subscriptions, resource groups, and resources
beneath it. It does not flow upward.

Management-plane ≠ data-plane. This is one of the most tested
distinctions on the exam:

Storage Account Contributor lets you manage the storage account — it does not grant access to blob data
Storage Blob Data Contributor grants blob data access
A user with an account access key bypasses RBAC entirely — they can read any content regardless of their role assignments

Contributor cannot delegate. If a user needs to assign roles to others
on a specific resource, Contributor alone is not enough. You need
User Access Administrator or Owner for that scope.

Azure Policy does not apply retroactively. An append policy only
affects newly created resources. Existing resources at the time of
assignment keep their current state.

Resource locks apply at: resource, resource group, and subscription
level. Management groups do not support resource locks.

Budgets do not stop anything. When a Budget threshold is reached, Azure
sends a notification. It does not deallocate VMs, pause services, or
block new deployments — regardless of how far over budget you go.

Two lock types:

CanNotDelete — read and modify allowed, delete blocked
ReadOnly — no modifications or deletes permitted

Dynamic groups require Azure AD Premium P1. Static groups do not.

📖 Full breakdown of every sub-topic in this domain:
AZ-104 Domain 01 — Identities and Governance

Domain 02 — Storage (15–20%)

Three SAS types — know which works when:

User delegation SAS — backed by Entra ID credentials, works even when account key access is disabled
Service SAS — signed with account key, blocked when account key access is disabled
Account SAS — also signed with account key, blocked when account key access is disabled

If the exam disables account key access, user delegation SAS is the only
type that continues to function.

SAS effective permissions = intersection of RBAC role + SAS permissions.
The SAS cannot grant more than the role allows.

Redundancy options at a glance:

LRS — 3 copies in one datacenter
ZRS — 3 copies across availability zones in one region
GRS — LRS + async replication to a secondary region
GZRS — ZRS + async replication to a secondary region
RA-GRS / RA-GZRS — read access to the secondary region

Archive tier is offline. Blobs in Archive cannot be read without
rehydration first. This adds delay. Blobs in Cool or Hot tier are
immediately readable.

Minimum storage durations:

Hot — no minimum
Cool — 30 days (early deletion = penalty)
Cold — 90 days (early deletion = penalty)
Archive — 180 days (early deletion = penalty)

Lifecycle rules apply to new state, not past state. When a blob
matches two rules simultaneously, the more restrictive action wins.

Soft delete vs versioning:

Soft delete protects against accidental deletion
Versioning protects against accidental overwrites

📖 Full sub-topic breakdown including SAS gotchas and lifecycle JSON
rules: AZ-104 Domain 02 — Storage

Domain 03 — Compute (20–25%)

Bicep/ARM deployments are idempotent. Deploying the same template
multiple times will not cause errors — it brings resources to the declared
state.

Availability sets vs availability zones:

Availability sets — protect against hardware failures and planned maintenance within a single datacenter (fault domains and update domains)
Availability zones — protect against full datacenter failure within a region

Fault domains vs update domains in availability sets:

Fault domains — separate physical hardware (power, network). Protects against hardware failures.
Update domains — separate groups for planned maintenance. Only one update domain is rebooted at a time.

VMSS autoscale cooldown matters. The exam will give you a starting
instance count, a CPU threshold, and a cooldown window, then ask you to
calculate the count after a sequence of events. No scale event can fire
during the cooldown period after the previous one.

App Service plan OS is a hard constraint. A Windows plan cannot host a
Linux runtime stack (Python, for example). This drives the minimum plan
count when multiple apps have different runtime requirements.

Deployment slots are not free. Slot support requires Standard tier or
above. If the Slots option is greyed out, you need to scale up (not
scale out) the plan.

Container Apps minimum subnet size: /27 for workload profiles
environment — make sure you know how to check remaining address space in a
VNet before deploying.

📖 Full compute sub-topic breakdown including ARM/Bicep, containers, and
App Service: AZ-104 Domain 03 — Compute

Domain 04 — Networking (15–20%)

VNet peering is not transitive. VNet A peered with VNet B, VNet B
peered with VNet C — VNet A cannot reach VNet C. This is one of the
most commonly tested networking facts.

Overlapping address spaces cannot be peered. You must modify one VNet's
address space before peering is possible.

Azure Bastion — SKU differences:

Basic SKU — browser-based access only (Azure portal)
Standard SKU — native client access (mstsc.exe, SSH client)
Bastion reach follows one hop of direct peering only — VMs on VNet2 (directly peered with VNet1 where Bastion lives) are reachable; VMs on VNet3 (only peered with VNet2) are not.

AzureBastionSubnet minimum size: /26 for Standard SKU. Public IP must
be Standard SKU, static assignment, IPv4.

NSG regional constraint. An NSG can only be associated with subnets in
the same region as the NSG. Cross-region association is not possible.

NSG on subnet ≠ control over App Service inbound traffic unless the app
is deployed into that subnet (App Service Environment / Isolated tier). A
VNet-integrated app using the subnet for outbound traffic is not controlled
by a subnet NSG for inbound requests.

Standard Load Balancer requirements: Standard SKU public IPs only.
VMs must have an NSG configured. IPv6 addresses are not supported as
frontend IPs on a Standard public load balancer.

Private endpoint vs service endpoint:

Private endpoint — gives a PaaS resource a private IP in your VNet, traffic stays off the public internet
Service endpoint — optimises routing to the PaaS service but does not give it a private IP

📖 Full networking sub-topic breakdown including NSG rules, Bastion, DNS,
and peering: AZ-104 Domain 04 — Networking

Domain 05 — Monitor and Maintain (10–15%)

Recovery Services vault vs Backup vault — know which protects what:

Recovery Services vault — Azure VMs, Azure Files, SQL in Azure VMs, on-premises workloads
Backup vault — Azure Managed Disks, Azure Database for PostgreSQL, Azure Blobs at account level
Blob containers cannot be protected by either vault — use blob soft delete or versioning instead

Alert rules target the Log Analytics workspace, not the VM, when
monitoring Windows event log entries. Event log data is collected into the
workspace — the alert must target the workspace.

Budgets send notifications. They do not stop resources. (Worth
repeating — this appears in both Domain 01 and Domain 05 contexts.)

Alert suppression rules prevent notifications, but the alert still fires
and appears in the portal. Suppression ≠ cancelling the alert.

Activity log alert scope inheritance: An operation on a resource
triggers alerts scoped to that resource AND alerts scoped to its parent
resource group. An operation on the resource group itself only triggers the
RG-scoped alert — not any resource-scoped alerts.

Site Recovery subnet matching: During test failover, Site Recovery maps
source subnets to target subnets by matching subnet names. If the same
subnet name exists in the target VNet, the VM is connected to it.

📖 Full monitoring and backup sub-topic breakdown:
AZ-104 Domain 05 — Monitor and Maintain

One More Thing

A cheat sheet gets you through the last 48 hours. What gets you through
the exam itself is working through real scenario-based questions under
timed conditions — the format the AZ-104 actually uses.

If you haven't done full-length timed practice tests yet, that's the
highest-leverage thing you can do before exam day.

→ Try a FREE AZ-104 Practice Test on CrackCerts

→ 4 Weeks of AZ-104 Study

Good luck. You've got this.