AZ-104 cheat sheet

Manage Azure identities and governance

Manage Microsoft Entra Users and Groups (AZ-104)

• Microsoft Entra ID (formerly Azure Active Directory) is Azure's cloud identity service holding all users and groups.
• Member users are internal accounts; guest users are external collaborators invited through B2B who sign in with their own home credentials.
• Provision or remove many accounts at once with CSV-driven bulk create, bulk invite, and bulk delete operations.
• Security groups grant access, roles, and licenses; Microsoft 365 groups add shared collaboration resources like a mailbox, SharePoint site, and Teams.
• Assigned membership is maintained manually; dynamic membership adds and removes members automatically from an attribute rule and requires Microsoft Entra ID P1.
• A dynamic rule such as user.department -eq "Sales" auto-includes everyone in the Sales department and drops them when the attribute changes.
• Group-based licensing assigns product licenses to a group so members inherit them, and pairs powerfully with dynamic groups (set usage location or licensing fails).
• SSPR lets users reset their own passwords; Entra ID is a flat cloud directory with no OUs or Group Policy, unlike on-premises Active Directory.

Manage Access to Azure Resources: Azure RBAC (AZ-104)

• Azure RBAC is the authorization system that controls access to Azure resources; Microsoft Entra ID handles authentication.
• Every role assignment has three parts: a security principal (who), a role definition (what), and a scope (where).
• Owner has full access including managing access; Contributor manages resources but cannot grant access; Reader is view-only; User Access Administrator manages access but not resources.
• Scopes form a hierarchy — management group > subscription > resource group > resource — and a higher-scope assignment is inherited downward.
• Assign Reader once at the subscription and every child resource group and resource inherits it.
• Permissions are additive across all direct, inherited, and group assignments; explicit deny assignments override any allow.
• Create a custom role (JSON with Actions, NotActions, and AssignableScopes) only when no built-in role fits.
• Azure RBAC manages Azure resources; Microsoft Entra roles (such as Global Administrator) manage identity — they are separate systems.

Azure Subscriptions, Policy, Locks and Governance (AZ-104)

• The Azure hierarchy is management group → subscription → resource group → resource, and governance applied at a higher scope is inherited by everything beneath it.
• Management groups let you assign policy and access to many subscriptions at once; moving a subscription to a new management group makes it inherit that group's governance.
• Azure Policy governs what configuration is allowed; an initiative (policy set) is a group of policy definitions managed and assigned as one unit.
• Audit reports non-compliant resources while Deny blocks non-compliant create or update requests; deployIfNotExists and modify can remediate existing resources.
• Policy answers "what is allowed" and RBAC answers "who can act" — even an Owner is stopped by a Deny policy.
• Resource locks apply regardless of RBAC: CanNotDelete blocks deletion, ReadOnly blocks modify and delete, and locks are inherited by child resources.
• Tags are not inherited by default but can be enforced and inherited with Policy; Microsoft Cost Management provides cost analysis, budgets with alerts, and Azure Advisor cost recommendations.

Implement and manage storage

Configure Access to Azure Storage: SAS, Keys & Firewalls (AZ-104)

• Storage access has two layers: networking (firewall, virtual network rules, private endpoints) and authorization (keys, SAS, Entra RBAC) — decide them separately.
• Storage firewalls restrict access to selected virtual network subnets via service endpoints and to public IP ranges; private endpoints remove public exposure entirely.
• The two account access keys grant full, all-or-nothing control; keep two so you can rotate without downtime, and regenerating a key invalidates every SAS signed with it.
• A SAS grants scoped, time-limited access defined by permissions, start and expiry time, allowed IP, protocol, and signed resources; the three types are account SAS, service SAS, and the most secure user delegation SAS signed with Entra credentials.
• Use a stored access policy so you can revoke or modify an already-issued service SAS server-side, without regenerating account keys.
• Prefer Microsoft Entra ID with Azure RBAC whenever the caller has an identity; ranked most to least secure: Entra RBAC, user delegation SAS, service SAS, access keys.
• Identity-based access lets Azure Files SMB shares authenticate with AD DS or Microsoft Entra; share-level access uses RBAC roles while file-level access uses NTFS ACLs.

Configure & Manage Azure Storage Accounts and Redundancy (AZ-104)

• General-purpose v2 (GPv2) is the default account kind, supporting all services and access tiers; choose Standard performance for most workloads and Premium for low-latency, high-transaction needs.
• Every redundancy option keeps at least three copies: LRS stays in one datacenter, ZRS spans three availability zones, and GRS and GZRS add a second region.
• Use GRS or GZRS to survive a full region outage, and ZRS to survive a zone or datacenter outage within a single region.
• RA-GRS and RA-GZRS are the only options that let you read from the secondary region without a failover — the exact trigger is "read from the secondary."
• Object replication asynchronously copies block blobs between two storage accounts and requires blob versioning enabled on both the source and destination.
• Encryption at rest is always on (Storage Service Encryption with 256-bit AES); you can switch to customer-managed keys in Key Vault or add infrastructure encryption for double encryption.
• Manage data with Azure Storage Explorer (GUI, interactive) or AzCopy (command-line, scriptable bulk and account-to-account transfers).

Configure Azure Files and Azure Blob Storage (AZ-104)

• Azure Files provides managed SMB and NFS file shares you mount like a network drive; Azure Blob Storage provides containers of block, append, and page blobs for object data.
• Create a file share with a protocol and quota, mount SMB over port 445, and use a premium FileStorage account for NFS or low-latency workloads.
• Protect Azure Files with incremental share snapshots (recover individual files) and soft delete (recover a whole deleted share within a 1–365 day retention window).
• Azure File Sync keeps an on-premises Windows Server in sync with an Azure file share, and cloud tiering caches hot files locally while tiering cold files to Azure.
• A blob container's public access level is private (credential required), blob (anonymous read of known URLs), or container (anonymous read and list) — keep it private by default.
• Hot, cool, and cold are online tiers read instantly; archive is offline and cheapest to store but must be rehydrated (Standard up to ~15 hours, or High) before you can read it.
• Soft delete recovers accidentally deleted blobs and containers within a retention window; blob versioning automatically keeps previous versions when a blob is overwritten.
• Blob lifecycle management rules act on blob age to auto-transition to cooler tiers and delete data — e.g. cool at 30 days, archive at 90, delete at 365.

Deploy and manage Azure compute resources

ARM Templates and Bicep: AZ-104 Deployment Guide

• An ARM template is JSON with parameters, variables, resources, and outputs; parameters are supplied at deployment, outputs are returned after it.
• Bicep is a cleaner declarative language that transpiles to ARM JSON, infers dependencies from symbolic references, and can do anything ARM JSON can.
• Incremental mode (the default) adds and updates resources and leaves everything else untouched.
• Complete mode deletes any resource in the resource group that is not defined in the template — the classic accidental-deletion gotcha.
• Templates are idempotent: redeploying the same file is safe and only changes what differs from the current state.
• Export a template from a resource group or the deployment history to capture resources you built by hand.
• Convert ARM JSON to Bicep with bicep decompile, and Bicep to ARM JSON with bicep build.
• Deploy via the portal, az deployment group create, or New-AzResourceGroupDeployment, targeting a resource group, subscription, management group, or tenant.

Azure Virtual Machines: Sizes, Disks, and Zones (AZ-104)

• Creating a VM requires five choices: image, size, admin credentials, resource group, and region; the VM attaches to a network interface (NIC).
• VM size families map to workloads — B and D are general purpose, F is compute optimized, and E is memory optimized; resizing to a size on different hardware requires stopping (deallocating) the VM.
• Managed disk types range from Standard HDD (cheapest) through Standard SSD and Premium SSD to Ultra Disk (highest IOPS and lowest latency); data disks can be added online and expanded but not shrunk.
• Availability zones spread VMs across separate datacenters in a region for a 99.99% SLA and survive a whole-datacenter failure.
• Availability sets spread VMs across fault and update domains within one datacenter for a 99.95% SLA, protecting against rack failure and planned maintenance.
• A Virtual Machine Scale Set runs many identical, load-balanced VMs that autoscale with demand and can span zones.
• Encryption at host encrypts the VM's temp disk and disk caches on the physical host, unlike Azure Disk Encryption's in-guest BitLocker or dm-crypt.
• Moving a VM to another resource group or subscription is a native Move; moving to another region uses Azure Resource Mover.

Provision and Manage Containers in Azure (AZ-104)

• Azure Container Registry (ACR) is a private, managed registry that stores container images; ACI, Container Apps, and AKS pull from it.
• ACR SKUs are Basic, Standard, and Premium; geo-replication and private endpoints are Premium-only, and a managed identity lets services pull images without stored credentials.
• Azure Container Instances (ACI) runs a single container or container group serverlessly, bills per second, and has no autoscaling, ideal for short, isolated, or bursty tasks.
• Azure Container Apps runs serverless containers with automatic scale rules, scale-to-zero, HTTPS ingress, and revisions, ideal for microservices and event-driven workloads.
• Sizing in ACI is a fixed CPU and memory request; Container Apps adds min/max replicas plus scale rules driven by HTTP, CPU, or KEDA events.
• Choose ACI to run something once with no orchestration, Container Apps to autoscale managed containers, and AKS only when you need full Kubernetes control.

Create and Configure Azure App Service (AZ-104)

• Azure App Service is a managed PaaS for web apps and APIs; every app runs on an App Service plan, which is the compute you pay for.
• The plan's pricing tier (Free, Shared, Basic, Standard, Premium, Isolated) decides compute, whether apps share hardware, and which features are available.
• Scale up changes the tier for bigger instances; scale out adds more instances, manually or with autoscale rules (Standard tier and above).
• Custom TLS bindings need Basic tier; autoscale, deployment slots, and scheduled backups need Standard or higher.
• Map a custom domain with a CNAME or A record plus a TXT verification record, secure it with a managed or uploaded certificate, and force HTTPS with HTTPS Only.
• Deployment slots (Standard and above) let you test in a staging slot then swap with production for zero-downtime deployment and instant rollback; sticky slot settings stay with their slot.
• Use VNet integration for outbound access and access restrictions or private endpoints for inbound access.

Implement and manage virtual networking

Azure Virtual Networks, Subnets, Peering & User-Defined Routes

• Azure reserves five IP addresses in every subnet (network, gateway, two for DNS, broadcast), so a /24 yields 251 usable hosts.
• VNet peering connects two VNets over the Microsoft backbone; regional peering is same-region and global peering spans regions.
• Peering is non-transitive: A-to-B plus B-to-C does not connect A to C — each pair needs its own peering.
• Use Allow gateway transit on the hub and Use remote gateways on the spoke so spokes share the hub's VPN or ExpressRoute gateway.
• Standard SKU public IPs are static-only and secure by default; Basic SKU is being retired, so prefer Standard.
• A user-defined route with next hop type Virtual appliance forces traffic through a firewall or NVA; enable IP forwarding on the appliance NIC.
• Network Watcher's IP flow verify, Next hop, and Effective routes diagnose NSG and routing problems quickly.

Azure NSGs, Bastion, Service Endpoints & Private Endpoints

• NSG rules use priority 100-4096 where a lower number means higher priority, and Azure stops at the first matching rule.
• Every NSG rule is a 5-tuple: source, source port, destination, destination port, and protocol, with an allow or deny action.
• NSGs apply at the subnet level, the NIC level, or both; when both apply, traffic must pass both, so the most restrictive rule wins.
• Application security groups let you reference VMs by workload in NSG rules instead of by IP address, so rules survive scaling.
• Effective security rules combine subnet and NIC NSGs into one merged view to show exactly which rule allows or blocks traffic.
• Azure Bastion gives browser-based RDP and SSH over TLS with no public IP on the VM, from a subnet named AzureBastionSubnet.
• A service endpoint keeps the PaaS public endpoint but routes over the backbone; a private endpoint gives the service a private IP in your VNet.

Azure DNS and Load Balancer: AZ-104 Networking Guide

• A public Azure DNS zone hosts a domain's records (A, CNAME, MX, TXT) and becomes authoritative once you delegate the domain by updating the name servers at the registrar.
• A private DNS zone resolves VM names privately inside and between VNets via a virtual network link; enable autoregistration to have Azure create and remove VM A records automatically.
• Azure Load Balancer is a Layer 4 (TCP/UDP) distributor built from a frontend IP, a backend pool, health probes, and load-balancing rules.
• A public load balancer fronts a public IP for internet traffic; an internal load balancer fronts a private IP to distribute traffic across a private app tier inside the VNet.
• The Standard SKU is zone-redundant and secure by default (closed until an NSG allows traffic); Basic is legacy and being retired.
• Use Application Gateway for Layer 7 URL-path routing and WAF, and Traffic Manager for global DNS-based routing — not Azure Load Balancer.
• If a backend fails its health probe it is removed from rotation; when traffic stops distributing, check the probe port and path, the NSG allowing the AzureLoadBalancer tag, and backend health.

Monitor and maintain Azure resources

Azure Monitor: Metrics, Logs, Diagnostic Settings & Alerts (AZ-104)

• Azure Monitor collects two fundamental data types: metrics (numeric, time-series, near real time) and logs (structured events queried with KQL).
• Interpret metrics in Metrics Explorer using aggregations, filters, and splitting; metrics are collected automatically and need no query language.
• Logs live in a Log Analytics workspace and are queried with Kusto Query Language (KQL) for troubleshooting, correlation, and auditing.
• Diagnostic settings route platform logs and metrics to a Log Analytics workspace (analyze with KQL), a storage account (archive), or an event hub (stream to a SIEM).
• Alert rules fire on a metric or log condition; an action group defines who is notified and what happens — email, SMS, webhook, Azure Function, Logic App, or automation runbook.
• Alert processing rules suppress alerts during maintenance or route them at scale without editing each rule.
• VM insights (via the Azure Monitor Agent) monitors guest performance, while boot diagnostics helps diagnose a VM that will not start.
• Network Watcher diagnoses network paths, and Connection Monitor continuously tests reachability and latency between endpoints over time.

Azure Backup & Site Recovery: Vaults, Policies & Failover (AZ-104)

• A Recovery Services vault holds Azure Backup for VMs, Azure Files, and in-VM SQL/SAP, and is the vault Azure Site Recovery uses; the newer Azure Backup vault covers modern workloads like Azure databases, blobs, and managed disks.
• A backup policy is a schedule (how often backups run) plus retention (how long each recovery point is kept).
• Azure Backup protects against data loss, corruption, and ransomware by keeping point-in-time recovery points you restore from.
• Restore granularity for a VM ranges from creating a whole new VM, to replacing disks, to file-level recovery of individual files.
• Azure Site Recovery continuously replicates VMs to a secondary region so you can fail the workload over during a region or site outage.
• Failover comes in three forms: test (isolated, non-disruptive validation), planned (clean shutdown, no data loss), and unplanned (from the latest recovery point).
• The classic distinction: Backup protects against data loss and corruption with point-in-time restore; Site Recovery protects against a site or region outage by keeping the workload running elsewhere, measured by RPO and RTO.
• Backup center is the unified place to monitor backups, and backup alerts can flow through Azure Monitor action groups.