AZ-104 Cheat Sheet

A member user is native to your tenant (created in the cloud or synced from on-premises Active Directory by Entra Connect); a guest user is invited from another directory through B2B collaboration and signs in with their own home credentials. The type is decided by how the account entered the directory and is not something you toggle on the user. You widen or narrow a user's actual access by assigning roles, not by changing the type.

When an outside partner needs access, invite them as a B2B guest rather than creating a member account. The guest authenticates against their own home tenant or identity provider, so you issue no credential and reset no password, and you scope them with roles and group membership. A guest's UPN takes the form alice_contoso.com#EXT#@yourtenant.onmicrosoft.com, and by default guests have restricted directory permissions.

Trap Creating a member account for an external partner: it forces you to manage a credential and grants the broad default member permissions a partner shouldn't have.

By default a guest can manage their own profile and read only limited directory data; they cannot enumerate the full list of users or groups the way a member can. Members, by contrast, can read most directory information and by default register applications, create groups, and invite other guests. You can tighten these defaults for all members or all guests in the directory's user settings.

Pick a security group to manage access to resources, roles, and applications: its members can be users, devices, service principals, and even other groups (nesting). Pick a Microsoft 365 group when the need is a shared workspace (mailbox, calendar, SharePoint), but note its members can be users only. The decisive test is the requirement: resource or role access points to a security group, a team workspace points to a Microsoft 365 group.

Trap Choosing a Microsoft 365 group to control access to a resource: that group type is for collaboration, and only a security group can be used for group-based licensing.

A security group's membership can include users, devices, service principals, and nested groups, which is why it is the vehicle for assigning resource access and roles. A Microsoft 365 group accepts users only: no devices or service principals. When a scenario needs a group of devices (for example to target Intune policy through dynamic device membership), the group must be a security group.

Trap Trying to add devices to a Microsoft 365 group: that type takes users only, so a device group must be a security group.

Assigned membership means an administrator or group owner adds each member by hand; dynamic membership uses an attribute rule to add and remove members automatically as their attributes change. Choose Assigned for a fixed, hand-picked roster and dynamic when membership should track an attribute such as department. Dynamic keeps the roster accurate without manual upkeep but trades away the ability to pin or exclude an individual outside the rule.

Group ownership lets you manage a group's properties and its membership, but the membership part applies only to Assigned groups. A dynamic group's members are governed entirely by its rule, so even the owner cannot add or remove a member directly: you change membership by changing user attributes or the rule itself. Editing a dynamic membership rule additionally requires the Groups Administrator, Intune Administrator, or User Administrator role.

Trap Assuming a group owner can add a member to any group: for a dynamic group the rule controls membership and the owner cannot override it.

When you create a dynamic membership group you choose Dynamic User or Dynamic Device, and a single group cannot do both. A device rule may reference only device attributes: you cannot build a device group from the device owners' attributes. If a requirement mixes users and devices, you need two separate dynamic groups.

Trap Building one dynamic group whose rule mixes user and device attributes: Entra ID requires the membership target to be users only or devices only.

Attribute-rule (dynamic) group membership is a premium feature: it requires Microsoft Entra ID P1 for every user in scope of the rule. Assigned membership works on the free tier. In a scenario set in a trial or free tenant, automatic department-based membership is unavailable, so the answer falls back to an Assigned group plus manual upkeep, or acquiring P1.

Trap Proposing dynamic membership in a free/trial tenant: dynamic groups need Entra ID P1 and aren't available on the free tier.

A license cannot be assigned to a user until that user has a Usage location set, because Microsoft licenses are subject to regional availability. If a direct license assignment fails for a freshly created user, the missing Usage location attribute is the usual cause. Set it on the user profile, then assign the license.

Group-based licensing attaches one or more product licenses to a security group; Entra ID then licenses every member automatically and removes the license when a member leaves the group. Pair it with a dynamic group and licensing tracks org structure with zero scripting. It works on security groups only, and you must hold at least one license for every unique member of a licensed group.

Group-based licensing itself is a premium capability: you need Microsoft Entra ID P1 (or a qualifying Microsoft 365 / Office 365 plan such as Business Premium or Office 365 E3) for every user who benefits from it. This is separate from the product licenses being assigned: the P1 entitlement pays for the automation, while the product licenses cover the services the members consume.

Since September 1, 2024 the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI; assignment for both users and groups is done in the Microsoft 365 admin center. The change is UI-only: Microsoft Graph and PowerShell still assign licenses programmatically. If a question says the license-assignment option is missing from the Azure portal, that is expected, not a bug.

Trap Looking for the license-assignment blade in the Entra/Azure portal: it was removed in September 2024; assign licenses in the Microsoft 365 admin center or via Graph/PowerShell.

Self-service password reset lets users reset or unlock their own password with no help-desk call, but each user must first register authentication methods: choices include Microsoft Authenticator, OATH tokens, SMS, voice call, email OTP, and security questions. The administrator policy sets how many registered methods a reset requires, a value of one or two. A user who has registered fewer than the required number cannot use SSPR and must contact an administrator.

Even if the tenant SSPR policy requires only one method for ordinary users, accounts holding an Azure administrator role are subject to a stronger two-gate password reset policy and cannot use the relaxed single-method setting. This is automatic and not configurable down: Microsoft enforces it because admin accounts are higher-value targets.

Trap Assuming a one-method SSPR policy applies to administrators: admin-role accounts are always held to the stronger two-method reset policy.

Self-service password reset is available on Microsoft Entra ID Free for cloud-managed users. SSPR password writeback, which pushes a cloud-initiated reset back down to on-premises Active Directory for a federated, pass-through-auth, or password-hash-synced user, requires Microsoft Entra ID P1. Without writeback, a hybrid user whose password is mastered on-premises is told to contact their administrator instead of resetting.

Trap Expecting plain SSPR to reset a synced on-premises user's password: that needs SSPR password writeback, which requires Entra ID P1.

A password reset recovers a forgotten password (the SSPR scenario, where the user proves identity with registered methods); a password change updates a password the user already knows and is signed in with; password writeback is the hybrid mechanism that carries either operation back to on-premises AD. It is not a separate end-user action. Conflating reset with writeback is the usual source of confusion in hybrid scenarios.

A guest who signs in with a personal Microsoft account (Outlook.com, Hotmail) cannot use your tenant's Entra SSPR; they recover through their own Microsoft account instead. B2B guests from a partner Microsoft Entra tenant or self-service sign-up users, by contrast, can reset using the email they registered, subject to the partner tenant's own SSPR policy. So SSPR support for a guest depends on what kind of account backs them.

Trap Expecting your tenant's SSPR policy to reset a personal-Microsoft-account guest's password: those accounts recover through their own Microsoft account, not your tenant.

Bulk user creation in the Microsoft Entra admin center downloads a CSV template whose only required values are Name, User principal name, Initial password, and Block sign in (Yes/No). Extra columns you add are ignored and not processed, and a bulk operation can fail if it doesn't complete within about an hour, so split very large imports into smaller batches.

When a dynamic membership rule tests one property against several values, the single -in operator (for example user.department -in ["Sales","Marketing"]) is more efficient than chaining many -or/-eq expressions. Microsoft advises minimizing the -match and -contains operators as much as possible for better dynamic group processing times; prefer -eq or -startsWith where you can.

In the Microsoft Graph PowerShell SDK, New-MgUser creates a user (its PasswordProfile parameter takes a hash table such as @{Password='...'}), Update-MgUser edits an existing user's properties, and Get-MgUser piped to Update-MgUser bulk-updates a filtered set. Connect-MgGraph must request the User.ReadWrite.All scope to create or modify users.

Trap Passing PasswordProfile as a string, or requesting only User.Read.All (read-only) when you need to write.

Guest invitations are governed in External collaboration settings: you can restrict them so only users assigned to specific admin roles can invite, and the built-in Guest Inviter role grants invite rights (even when that restriction is on) without other user-management privileges. Collaboration restrictions can allow or block invitations to specific named domains (for example only fabrikam.com).

Trap Assigning User Administrator just to let someone invite guests when the least-privilege Guest Inviter role suffices.

Self-service password reset can be enabled for None, Selected, or All users; choose Selected and pick one security group to pilot it before a wider rollout. Turning on 'Require users to register when signing in' prompts users to supply authentication contact info at next sign-in, and the re-confirmation interval accepts 0 to 730 days (0 means users are never asked to re-confirm).

Trap Leaving SSPR set to All when only a pilot group is intended.

A Standard general-purpose v2 (StorageV2) account supports Blob, Azure Files, Queue, and Table storage together, and it is Microsoft's recommended kind for almost all new work. The premium kinds are single-purpose: premium block blobs (block/append blobs), premium file shares (Azure Files), and premium page blobs. Reach for a premium kind only when one service needs SSD-backed low latency or high transaction rates; otherwise StorageV2 keeps everything in one account.

The Standard performance tier runs on hard-disk drives and is the cost-effective choice for general blob, file, queue, and table workloads. The Premium tier runs on solid-state drives for low, consistent latency and high throughput, and it costs more. Pick Premium when a workload is latency-sensitive or has a high transaction rate against small objects; pick Standard for everything else.

You choose the account kind and performance tier when you create a storage account, and you cannot convert an account to a different type afterward. To move from Standard to Premium (or change kind), you create a new account and copy the data across with a tool like AzCopy. The single exception is the one-way in-place upgrade of a legacy general-purpose v1 or BlobStorage account to general-purpose v2.

Trap Assuming you can switch a Standard account to Premium in the portal. There is no in-place tier change; you must create a new account and copy the data.

A storage account name must be between 3 and 24 characters, contain only lowercase letters and numbers (no hyphens, underscores, or uppercase), and be unique across all of Azure because it forms the subdomain of every endpoint, such as account.blob.core.windows.net. A name that is taken anywhere in Azure, or that uses an illegal character, is rejected at creation.

Within the primary region you choose LRS (three copies in one datacenter) or ZRS (synchronous copies across three availability zones). Layering a distant secondary region on top gives the geo options: GRS (LRS in primary + async copy to the paired region) or GZRS (ZRS in primary + async copy). The redundancy setting is account-wide, so every service in the account shares one durability profile.

Locally redundant storage replicates data three times within a single physical datacenter in the primary region and gives at least eleven 9s (99.999999999%) of durability over a year. It is the lowest-cost option and protects against drive, server, and rack failures, but if that datacenter is destroyed, every replica is lost. Choose it only when data is easily reconstructed or residency rules forbid leaving the region and a zone outage is acceptable.

Trap Treating LRS as protection against a datacenter or zone outage. All three LRS copies sit in one datacenter, so losing it loses everything.

Zone-redundant storage writes data synchronously across three availability zones in the primary region (each a separate datacenter with independent power, cooling, and networking) and gives at least twelve 9s (99.9999999999%) durability. Reads and writes keep working through a full zone outage. It is the right within-region choice when you must survive losing a whole datacenter but data must stay in the region.

Both geo options copy data asynchronously to a paired secondary region hundreds of miles away and give at least sixteen 9s (99.99999999999999%) durability. The only difference is the primary region: GRS uses LRS there, GZRS uses ZRS there (so GZRS also survives a primary-region zone outage). In the secondary region both always use LRS. Use a geo option to survive a region-wide disaster.

Trap Thinking GRS and GZRS differ in the secondary region. Both use LRS in the secondary; the difference (LRS vs ZRS) is entirely in the primary region.

When you create a geo-redundant account you pick the primary region; Azure determines the paired secondary region automatically, and it cannot be changed. The pairing is a hundreds-of-miles-away region in the same geography, so you can't, for example, point a West Europe account's secondary at a US region. If a scenario needs a specific secondary, geo-redundancy can't deliver it.

Writes commit in the primary region first and replicate to the secondary asynchronously, so the secondary trails the primary. The gap between the last primary write and the last write that reached the secondary is the recovery point objective (RPO), and it is non-zero: a disaster that destroys the primary before it catches up loses that window of data. This is the inherent trade for cross-region protection.

With plain GRS or GZRS the secondary copy exists for durability but is inaccessible during normal operation; you cannot read or write it. If the primary region is lost, you trigger a customer-managed account failover, after which the secondary becomes the new primary and serves reads and writes. To read the secondary before any failover, you instead need the read-access variant.

Trap Expecting to read a plain GRS account's secondary copy during a primary outage. GRS gives no secondary read access; that requires RA-GRS, or an account failover first.

The read-access variants RA-GRS and RA-GZRS let an application read the secondary copy at any time (including before a failover) through a read-only endpoint formed by appending -secondary to the account name (e.g. myaccount-secondary.blob.core.windows.net), using the same access keys. Choose RA- when the app must keep serving reads during a primary-region outage without waiting for failover.

Azure Files supports LRS, ZRS, and the geo options GRS and GZRS, but it does not support read access to the secondary region: there is no RA-GRS or RA-GZRS for file shares. If a requirement asks to read a file share's secondary copy before failover, it cannot be satisfied; plan failover-based recovery instead. (RA- read access applies to Blob, Queue, and Table.)

Trap Choosing RA-GRS for an Azure Files share to get secondary read access. Azure Files doesn't support the RA- variants, only LRS/ZRS/GRS/GZRS.

The archive access tier for block blobs is supported only on LRS, GRS, and RA-GRS accounts. It is not supported on ZRS, GZRS, or RA-GZRS. So if a scenario both requires zone redundancy and uses the archive tier, those constraints conflict and you can't have both on the same account.

Trap Putting archive-tier blobs in a GZRS or ZRS account. The archive tier isn't supported on any zone-redundant option; use LRS, GRS, or RA-GRS.

Object replication is a blob feature, separate from account redundancy: it asynchronously copies block blobs from a source storage account to a destination account you can read and use directly, to cut read latency in a distant region, distribute compute, or stage results. It is one-directional, and the source and destination can be in the same or different regions, subscriptions, or even Microsoft Entra tenants.

Before object replication works, blob versioning must be enabled on both the source and destination accounts, and change feed must be enabled on the source (Azure reads the change feed to discover new writes to replicate). Both accounts must be general-purpose v2 or premium block blob. Miss any of these prerequisites and the policy won't replicate.

Trap Enabling object replication without turning on blob versioning on both accounts and change feed on the source. Those are hard prerequisites, not optional.

Object replication supports block blobs exclusively; append blobs and page blobs are not replicated, and accounts with a hierarchical namespace (Data Lake Storage) aren't supported. If a workload needs to replicate page or append blobs, object replication is the wrong tool. By default a rule copies only new block blobs written after the rule is created, though you can opt to also copy existing blobs.

Trap Expecting object replication to copy page or append blobs. It copies block blobs only; the others are unsupported.

Object replication is one-directional: once a policy is active, the destination container rejects writes with HTTP 409 (Conflict). Reads and deletes are allowed, but to write to the destination you must first remove the rule or the whole policy. You create the policy on the destination account (Azure assigns a policy ID), then apply that same policy ID on the source so both ends match.

Every storage account encrypts all data at rest automatically with 256-bit AES service-side encryption, which is FIPS 140-2 compliant and covers blobs, files, queues, and tables (including metadata, every access tier, and both primary and secondary regions). There is no option and no cost to turn it off: the only thing you configure is who controls the key.

Trap Treating storage encryption at rest as an optional setting you enable. It is always on and can't be disabled; only key management is configurable.

By default a storage account encrypts with a Microsoft-managed key (Microsoft stores and rotates it, zero config). Switch to a customer-managed key (CMK) when you must control rotation, auditing, or revocation. You can switch between Microsoft-managed and customer-managed keys at any time, and applying a CMK to an existing account takes effect immediately without re-encrypting your data.

A customer-managed key must be stored in Azure Key Vault or Azure Key Vault Managed HSM, and that vault must have both soft delete and purge protection enabled. The storage account accesses the key through a managed identity (system-assigned or user-assigned) that holds get, wrapKey, and unwrapKey permissions on the key. The CMK wraps the account's root encryption key rather than encrypting data directly, so disabling the key in the vault revokes access (operations then fail 403) without re-encrypting anything.

Trap Configuring a CMK on a key vault without soft delete and purge protection enabled. Both are required, or the configuration is rejected.

Infrastructure encryption adds a second layer: data is encrypted twice, once at the service level and once at the infrastructure level, with two different 256-bit AES keys and algorithms, so a single compromised key or algorithm still leaves data protected. The infrastructure layer always uses a separate Microsoft-managed key even if the service layer uses your CMK. The catch: it can only be enabled when the account is created, you can't add it to an existing account.

Trap Planning to enable infrastructure (double) encryption on an existing account. It's a create-time-only option; you'd have to make a new account and copy the data.

AzCopy is a cross-platform command-line utility (Windows, Linux, macOS) for copying data to, from, or between storage accounts, the right tool for scripted, repeatable, or bulk transfers. Azure Storage Explorer is a free desktop GUI for point-and-click browsing and management, ideal for occasional interactive work; it uses AzCopy under the hood for its bulk transfers. Choose AzCopy when a scenario says 'script', 'automate', or 'large/efficient'; choose Storage Explorer for an occasional manual upload.

Trap Reaching for Storage Explorer's GUI to move terabytes in a repeatable script. That's AzCopy's job; Storage Explorer is for interactive, ad hoc use.

AzCopy's two core commands: azcopy copy copies source data to a destination (local-to-Azure, Azure-to-local, or account-to-account server-to-server), and azcopy sync performs one-directional synchronization so the destination ends up matching the source, transferring only what changed on re-runs. Use sync when you must keep a destination continuously aligned with a source rather than copying everything each time.

AzCopy supports two authorization methods: Microsoft Entra ID (run azcopy login once and reuse the credential across commands) or a shared access signature (SAS) token appended to each source or destination URL. Owning the storage account does not by itself grant data access, so you must provide one of these. Entra ID suits interactive or managed-identity use; a SAS token suits handing scoped, time-limited access to a script without sign-in.

A key expiration policy sets an interval and surfaces a reminder in the portal when the access keys haven't been rotated in time. It does not rotate keys automatically. You cannot create the policy until each access key has been rotated at least once; if keyCreationTime is null the Set rotation reminder option is greyed out. The built-in Azure Policy 'Storage account keys should not be expired' then reports which accounts are out of compliance.

An availability set is a single-datacenter grouping that spreads VMs across fault and update domains, but the 99.95% Azure SLA applies only when you place two or more VMs in the set: a set with one VM gives no redundancy and no set-level SLA. The set itself is free; you pay only for the VM instances. Because the spreading is inside one datacenter, it protects against hardware, power, and switch failures but not a datacenter-wide outage.

Trap Expecting the 99.95% availability-set SLA from a single VM in the set. The SLA requires two or more VMs across the fault domains.

Availability zones are physically separate zones within a region, each with independent power, cooling, and networking, and every zone-enabled region has three of them. Spreading a workload's VMs across two or more zones earns the 99.99% SLA and survives the loss of a whole datacenter, the resilience an availability set cannot provide. The cost is slightly higher VM-to-VM latency than an availability set, whose VMs are physically closer.

Azure grants a 99.9% single-instance VM SLA, but only when the OS and all data disks are Premium SSD or Ultra Disk; a VM using Standard storage gets no single-instance SLA. This is the floor option with no redundancy grouping, appropriate only when an outage of that one VM is tolerable. For anything that must stay up, spread VMs across an availability set or zones.

Trap Claiming a single VM with Standard HDD/SSD disks carries the 99.9% SLA. The single-instance SLA requires Premium SSD or Ultra Disk on every disk.

Azure assigns each VM in an availability set a fault domain (a group sharing a power source and network switch, up to 3) and an update domain (a group rebooted together during planned maintenance, up to 20). Only one update domain reboots at a time, with 30 minutes to recover before the next. Both counts are set when the availability set is created and cannot be changed afterward, so size them up front.

The two domain types answer different failure modes. A fault domain is a physical boundary: VMs in different fault domains don't share a power source or network switch, so a hardware fault hits only one. An update domain is a maintenance boundary: Azure reboots update domains one at a time during host updates, so a planned reboot never takes the whole set down at once. An availability set distributes VMs across both simultaneously.

Availability sets provide redundancy but have no automatic scaling: the instance count is whatever you deployed. When a workload must add instances under load and remove them when idle, you need a Virtual Machine Scale Set, which autoscales horizontally on a metric (such as average CPU) or a schedule. Reach for the availability set only when the instance count is fixed and you just need redundancy.

Trap Choosing an availability set for a workload that must scale out and in with demand. Availability sets never autoscale; a Virtual Machine Scale Set does.

A Virtual Machine Scale Set's orchestration mode is chosen at creation and can never be changed. Flexible orchestration is Microsoft's recommended mode: it manages standard IaaS VMs with the normal VM APIs, scales to 1,000 instances, can mix VM sizes, operating systems, and Spot with on-demand instances, and spreads instances across fault domains and availability zones. Uniform orchestration instead deploys identical instances from one profile for very large, homogeneous fleets.

Trap Planning to switch a scale set from Uniform to Flexible later. Orchestration mode is immutable after the scale set is created.

Autoscale on a Virtual Machine Scale Set is horizontal: it adds instances (scale out) when a metric crosses a threshold and removes them (scale in) when load drops, or follows a schedule. Increasing an individual VM's vCPU/memory is vertical scaling and is a resize operation, not autoscale. A question describing 'more power per instance' points to a resize; 'more instances under load' points to scale-set autoscale.

Trap Treating a VM resize (bigger SKU) as autoscale. Autoscale changes the instance count horizontally, while a resize changes one VM's size vertically.

The five managed disk types in ascending performance are Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk, with IOPS ceilings of about 2,000–3,000, 6,000, 20,000, 80,000, and 400,000 respectively. The OS disk must be Premium SSD, Standard SSD, or Standard HDD: Ultra Disk and Premium SSD v2 are data-disk-only. A high-IOPS database VM therefore pairs a Premium SSD OS disk with an Ultra or Premium SSD v2 data disk.

Trap Selecting Ultra Disk or Premium SSD v2 as the OS disk. Both can only be attached as data disks; the OS disk falls back to Premium SSD, Standard SSD, or Standard HDD.

Ultra Disk supports single-VM and availability-zone deployments but not availability sets. A scenario that needs both the highest disk IOPS (Ultra Disk) and platform redundancy must use an availability zone, not an availability set. This pairs with Ultra's other limits: it can't be an OS disk and doesn't support disk caching.

Trap Attaching an Ultra Disk to a VM in an availability set. Ultra Disk is unsupported there; use a single VM or an availability zone instead.

Every VM has a temp disk (drive D: on Windows, /dev/sdb on Linux) for scratch data such as a page or swap file. It is local to the host, not a managed disk, and its contents are wiped on deallocation or when Azure migrates the VM to another host. Anything that must survive belongs on the OS disk or a data disk, both of which are persistent managed disks.

Trap Placing application data or a database file on the temp disk. It is wiped on deallocation/host migration, so durable data must go on a managed OS or data disk.

Server-side encryption (SSE), also called encryption-at-rest, is always enabled on managed disks and can't be turned off; it encrypts the OS and data disks with platform-managed keys, or customer-managed keys when you attach a Disk Encryption Set (DES). Its boundary is the testable point: SSE does not encrypt the temp disk or disk caches. To cover those, layer on encryption at host.

Trap Assuming default SSE encrypts the temp disk and caches. It covers only the persisted OS and data disks; the temp disk needs encryption at host.

Encryption at host extends SSE so the temp disk, disk caches, and data flowing between the VM and storage are all encrypted, and it runs on the Azure host rather than inside the guest, so it consumes no VM CPU. It is Microsoft's recommended encryption option for new VMs and is what Microsoft Defender for Cloud's 'encrypt temp disks, caches, and data flows' recommendation detects. Choose it when the temp disk must be encrypted without a guest agent.

Azure Disk Encryption (ADE) encrypts the OS and data disks from inside the guest OS (BitLocker on Windows, DM-Crypt on Linux) and integrates with Azure Key Vault to store the disk-encryption keys, so an ADE deployment requires a Key Vault. Because it runs in the guest, ADE uses the VM's CPU and doesn't work for custom Linux images. A stem naming BitLocker or DM-Crypt is describing ADE specifically.

Trap Configuring ADE without an Azure Key Vault. ADE stores its keys in Key Vault, so the deployment fails without one.

Azure Disk Encryption is scheduled for retirement on September 15, 2028, after which ADE-encrypted disks will fail to unlock on reboot. Microsoft directs new VMs to encryption at host, which covers more (temp disk and caches) without using VM CPU. For a new long-lived VM, encryption at host is the forward-looking answer; ADE remains only for the specific BitLocker/DM-Crypt-in-guest requirement.

Moving a VM to another resource group or subscription only re-parents it: the physical region is unchanged and the VM keeps running. To relocate a VM to a different region you must replicate it with Azure Resource Mover or Azure Site Recovery; the move-resource-group operation can't change a resource's region. A question asking how to move a VM 'to another region' is testing that distinction.

Trap Using a move-to-resource-group or move-to-subscription operation to relocate a VM to a new region. Those never change the region; use Azure Resource Mover or Site Recovery.

Moving a VM across subscriptions requires both subscriptions to belong to the same Microsoft Entra ID (formerly Azure Active Directory) tenant, and the VM must move together with its dependent resources (disks, NIC, and virtual network). During the move both the source and target resource groups are locked for up to four hours, so you can't create, delete, or resize resources in them while it runs.

Trap Expecting a cross-subscription move to work across two different Entra tenants. Both subscriptions must share one tenant first (transfer billing ownership otherwise).

Because a resource ID embeds the subscription and resource group, moving a VM changes its ID: any scripts, dashboards, or templates referencing the old ID must be updated. Azure role assignments are not carried across the move and become orphaned, so you must recreate them on the moved resource. Plan to re-point references and re-grant RBAC after a move.

A VM's size (SKU) fixes its vCPU, memory, and feature support, and sizes are grouped into families by purpose (general purpose, compute optimized, memory optimized, storage optimized, GPU). You can resize a running VM if its current host cluster supports the target size; if it doesn't (often when moving to a different family) the VM must be stopped (deallocated) first and restarts on a new cluster. Not every size is offered in every region.

Trap Assuming any resize is hot. Moving to a size the current host cluster doesn't support requires deallocating the VM first.

Neither a Virtual Machine Scale Set nor an availability set carries a charge for the grouping construct itself: billing is purely for the VM instances they contain (plus their disks and networking). This means the redundancy or autoscaling capability is free to adopt; cost scales only with the number and size of running instances.

A Custom Script Extension run is allowed up to 90 minutes; a script that runs longer fails the extension with a timeout. For long jobs, split the work into scripts that each finish inside 90 minutes. This 90-minute limit is an exception to the shorter timeout most other VM extensions use.

Trap Assuming the Custom Script Extension shares the shorter timeout of most VM extensions and letting a long job run past 90 minutes; it caps at 90 minutes and then fails with a timeout.

The Azure VM Agent must be installed and reporting Ready for any extension to install or run; if it is missing or unhealthy, extensions fail. The agent signals readiness over the Azure platform IP 168.63.129.16 (WireServer, ports 80/tcp and 32526/tcp), so a guest firewall or NSG that blocks it breaks extensions. An extension already in a failed provisioning state will also block any new extension until it is fixed.

Trap Blaming a failed extension on the script while a guest firewall or NSG blocks 168.63.129.16 or the VM Agent is unhealthy; the agent must report Ready and reach the WireServer IP first.

Azure Disk Encryption requires a Key Vault in the same region and subscription as the VM, with the vault's 'Enabled for disk encryption' access policy turned on. ADE is not supported on Basic or A-series VMs (or VMs with under 2 GB RAM), and you set VolumeType=All to encrypt both OS and data disks. You cannot apply ADE to a VM whose disks use server-side encryption with customer-managed keys (SSE + CMK).

Trap ADE (in-guest BitLocker/DM-Crypt) and SSE with customer-managed keys are mutually exclusive. Pick one.

A VM's availability set is fixed at creation; you cannot add or move an existing VM into (or between) availability sets. To do it, delete the VM while keeping its managed disks, then recreate the VM from those disks specifying the target availability set, which preserves the data.

Trap Expecting to move an already-running VM into an availability set in place; the set is fixed at creation, so you must delete and recreate the VM from its disks.

A new availability set defaults to 3 fault domains and 5 update domains (update domains can be raised up to 20). For VMs with managed disks, set the availability set sku.name to Aligned so storage fault domains align with compute. The maximum managed-disk fault domains varies by region (some regions support only 2) so configure no more fault domains than the region allows.

Trap Leaving an availability set on the default Classic SKU for managed-disk VMs; managed disks require the Aligned SKU so storage fault domains align with compute.

An Azure virtual network is scoped to a single region and a single subscription, yet it automatically spans all availability zones in that region, so you never split or size a VNet by zone. Resources in different subnets of the same VNet route to each other by default with no configuration. To connect VNets that are in different regions or subscriptions, you use peering, not a single larger VNet.

Every subnet loses five addresses to Azure: the network address (.0), the default gateway (.1), two for Azure-mapped DNS (.2 and .3), and the broadcast address (last). A /24 therefore gives 251 usable host IPs, not 256, and the smallest usable subnet is a /29 (8 minus 5 = 3 usable). This is why a /29 handed to you in a stem holds 3 VMs, not 6.

Trap Assuming a /29 gives 6 usable IPs by counting only the .0 and broadcast: Azure reserves three more (gateway and two DNS), leaving just 3.

Subnet delegation designates a subnet for a specific Azure PaaS service (such as Azure SQL Managed Instance or App Service integration) so that service can deploy its own instances into the subnet and manage relevant subnet settings. A delegated subnet is dedicated to that service. Use it when a managed service requires VNet injection rather than just a service or private endpoint.

VNet peering connects two virtual networks so resources reach each other by private IP, with traffic staying entirely on the Microsoft backbone: no public internet, no VPN gateway, and no encryption are involved. Regional peering connects VNets in the same region; global peering connects VNets across regions. Both can cross subscriptions and Microsoft Entra tenants and carry a nominal ingress/egress data charge.

Trap Assuming peering needs a VPN gateway or that traffic traverses the public internet: peered traffic is private on the Azure backbone with no gateway required.

If A peers with hub H and H peers with B, A still cannot reach B: peering never routes transitively through an intermediate VNet. To make a hub-and-spoke route spoke-to-spoke or spoke-to-on-premises, you put a network virtual appliance or firewall in the hub and steer traffic to it with user-defined routes (service chaining), or use Azure Virtual Network Manager / Virtual WAN. This non-transitivity is the single most-tested peering property.

Trap Assuming a spoke peered to a hub automatically reaches the hub's other peers: transit requires an NVA/gateway in the hub plus UDRs, not peering alone.

You cannot peer two VNets whose CIDR ranges overlap: for example two 10.0.0.0/16 networks. Plan address spaces up front, or re-IP / resize one VNet's range before creating the peering. Overlapping spaces make the routes ambiguous, so Azure blocks the peering.

Trap Trying to peer two VNets that both use 10.0.0.0/16: overlapping ranges are rejected; one side must be re-addressed first.

Because a VNet can have at most one gateway, gateway transit lets spokes use the hub's VPN or ExpressRoute gateway instead of deploying one each. It is a per-peering setting on both ends: enable Allow gateway transit on the hub side and Use remote gateways on the spoke side. A spoke that uses a remote gateway must not have its own gateway, and transit works on both regional and global peering.

Trap Setting Use remote gateways on a spoke that already has its own gateway: a VNet can have only one gateway, so the configuration is invalid.

The Basic public IP SKU was retired on September 30, 2025, so every new design uses the Standard SKU. Standard differs in three ways: allocation is always static, it is secure by default, and it is zone-redundant by default in zone-enabled regions. A public IP is a separate resource you attach for inbound internet connectivity; outbound already works through an Azure-assigned ephemeral address without one.

A Standard SKU public IP uses static allocation: the address is fixed at creation and stays until you delete the resource. This matters whenever something external depends on a stable address: firewall allow-lists, DNS A records, IP-based security models, or TLS certificates bound to the IP. (Basic's dynamic IPv4 could change when a VM was stopped and started, the classic 'why did my IP change?' cause.)

Standard SKU public IPs are secure by default: attaching one to a VM does not open inbound traffic. the resource stays closed until a network security group rule explicitly permits it. If a VM with a Standard public IP is unreachable, a missing NSG allow rule is the first thing to check. (Basic public IPs were open by default, which is the behavior people wrongly expect from Standard.)

Trap Expecting a Standard public IP to be reachable as soon as it's attached: it's secure by default, so inbound is blocked until an NSG rule allows it.

Each subnet automatically gets system routes: a Virtual network route for intra-VNet traffic, a 0.0.0.0/0 route to the Internet, and None routes that drop the RFC 1918 private ranges. You cannot create or delete system routes, but you can override specific ones with user-defined routes. Azure also adds optional system routes (Virtual network peering, Virtual network gateway) as you enable those features.

User-defined routes live in a route table you create and associate to a subnet (each subnet has zero or one table). A UDR's next hop is exactly one of: Virtual appliance, Virtual network gateway, Virtual network, Internet, or None. You cannot specify Virtual network peering or a service endpoint as a UDR next hop: Azure creates those route types only when you configure the feature itself.

Trap Trying to set 'Virtual network peering' or a service endpoint as a UDR next hop: only Azure creates those routes; they aren't selectable next-hop types in a UDR.

Forced tunneling overrides Azure's default internet route by adding a UDR for 0.0.0.0/0 whose next hop is a firewall appliance or the VPN/ExpressRoute gateway, then associating the route table to the subnet. All outbound traffic is then sent to that next hop for inspection or on-premises egress instead of going directly to the internet. This is the canonical use of a UDR.

You associate a single route table to a subnet, never two. Consolidate all custom routes into one table; longest-prefix-match and the UDR-over-system priority resolve precedence within it. A route table can be associated to many subnets, but each subnet points to only one table.

Trap Trying to attach two route tables to one subnet to combine rule sets: a subnet supports only one; merge the routes into a single table.

Azure selects a route by longest-prefix-match: 10.0.0.0/24 beats 10.0.0.0/16 for 10.0.0.5 because it is more specific, regardless of where each route came from. Source priority (user-defined route, then BGP route, then system route) is the tiebreaker only when two routes share the same prefix. That tie rule is exactly why a UDR for 0.0.0.0/0 overrides the default internet route.

Trap Assuming a UDR always beats a system route: a more-specific system prefix still wins by longest-prefix-match; UDR priority applies only on an exact prefix tie.

Routes for the VNet itself, for VNet peerings, and for virtual-network service endpoints are preferred system routes that a UDR cannot override, even with a more-specific prefix. In particular a service-endpoint route always wins for that service's addresses. This is the exception to the normal 'UDR overrides system route' rule.

Trap Writing a UDR to redirect service-endpoint or peering traffic: those preferred system routes can't be overridden, so the UDR is ignored for them.

The routes you author aren't necessarily the routes that run: Azure merges your UDRs with system and BGP routes and applies the selection rules, and the result is the effective routes on a network interface. View them per NIC (Portal Effective routes, or az network nic show-effective-route-table) to confirm the final next hop for a destination. A present 'Virtual network peering' route here is also your proof that a peering exists and is synced.

All resources in a VNet can reach the internet outbound by default, through an Azure-assigned ephemeral IP, even with no public IP attached. A public IP (or public load balancer) is required only for inbound reachability. This is why outbound connectivity 'just works' but a VM is not reachable from the internet until you give it a public endpoint.

Azure delivers a packet to a NIC only when the destination matches that NIC's own IP, so a VM used as a network virtual appliance silently drops forwarded traffic unless IP forwarding is enabled on its NIC. A Linux/Windows NVA must also enable forwarding inside the guest OS, not just on the Azure NIC.

Trap A correct UDR pointing at the NVA's private IP still black-holes traffic if NIC (or OS) IP forwarding is off.

Azure Monitor stores telemetry as two types. Metrics are numeric values sampled at regular intervals into a time-series database, so they are lightweight and near-real-time and you read them in Metrics Explorer. Logs are richer records held in a Log Analytics workspace and queried with Kusto Query Language (KQL). A number trending over time (CPU %, request count) is a metric; event-level detail (who deleted what, every failed request) is a log.

Trap Reaching for Log Analytics/KQL to chart a simple numeric trend: it works but needs data routed to a workspace first; Metrics Explorer already has platform metrics for free.

Platform metrics (built-in numeric counters) and the activity log (subscription control-plane events) are collected automatically with no configuration. Resource logs, the detailed per-operation logs a service emits, are off by default and produce nothing to query until you create a diagnostic setting. This gap is why a resource shows metrics instantly but its detailed logs are missing from your workspace.

Trap Assuming resource logs appear automatically because metrics did: only metrics and the activity log are automatic; resource logs need a diagnostic setting first.

A diagnostic setting does two jobs: it starts collecting resource logs, and it routes platform metrics, the activity log, or resource logs to a durable destination. Even auto-collected sources need a diagnostic setting to send them somewhere they outlive their default window. You opt platform metrics into a destination with the AllMetrics category, and pick log categories individually or via a category group (audit or allLogs).

Each Azure resource supports a maximum of five diagnostic settings. A single setting can send to several destinations at once but only one of each type, so two Log Analytics workspaces (or two storage accounts) require two separate settings, and you cannot exceed five total per resource.

Trap Trying to add a second workspace to one diagnostic setting: a setting allows only one destination of each type, so a second workspace needs a second setting (up to five).

The four destinations map to distinct jobs. A Log Analytics workspace is for querying and correlating with KQL, building workbooks, and firing log alerts. An Azure Storage account is the cheapest archive, kept indefinitely, for audit and compliance. Azure Event Hubs is the only destination that streams telemetry live to an external system such as a non-Microsoft SIEM. A partner solution hands off to an integrated third-party platform.

Trap Choosing a Storage account or Log Analytics workspace to feed a real-time external SIEM: only Event Hubs streams out; the others store data for later retrieval.

When security needs Azure logs streamed into a third-party SIEM in real time, route the diagnostic setting to Azure Event Hubs: the SIEM reads from the hub. When the requirement is keeping audit logs cheaply for years, route to an Azure Storage account, which can be kept indefinitely and supports an immutability policy for tamper-proof records. Storage and Log Analytics hold data; only Event Hubs pushes a live stream.

When reading a metric you choose one of five aggregations: Sum (total of all values in the interval, a.k.a. Total), Count (number of samples, ignoring their values), Average (the values' mean, normally Sum/Count), Min (smallest value), and Max (largest value). Picking the wrong aggregation misreads the data: Count on a request-duration metric tells you how many samples there were, not how long requests took.

Sum, Count, Min, and Max are pre-aggregated and stored, but Average is never stored: it is recomputed as Sum ÷ Count for the chosen grain. A short spike can vanish from Average and Sum at coarse granularity while still showing in Min and Max, so to catch transient anomalies inspect Max rather than trusting Average alone.

Trap Using Average to detect a brief spike: averaging smooths it out across the interval; Max is the aggregation that still surfaces the peak.

The minimum time granularity (time grain) for charting metrics is 1 minute; coarser grains are computed from the stored 1-minute values. Widening the grain trades detail for noise reduction, which is usually what you want before wiring a metric to an alert so a momentary CPU blip doesn't page you but a sustained one does.

Dimensions are name-value pairs attached to a metric (for example a per-instance breakdown). In Metrics Explorer you split a chart by a dimension to see each value as its own line, or filter to show only some. Splitting is how you turn an aggregated line that shows a spike into the specific instance responsible for it.

Logs from many resources can land in one Log Analytics workspace regardless of their subscription or region, and KQL queries that workspace across all of them. That is why a single log search alert can monitor resources spread across subscriptions and regions at once, whereas a metric alert is generally scoped to resources of one type in one region.

An alert rule binds three things: the target resource to watch, the signal and condition (a metric threshold, a KQL log query, or an activity-log event filter), and an action group to invoke when it fires. Keeping the action group separate from the rule means one action group serves many rules, so you maintain recipients in one place.

Metric alerts evaluate a metric against a static or dynamic threshold at regular intervals: fast and numeric. Log search alerts run a KQL query against workspace logs at a set frequency, for event detail and cross-resource conditions. Activity log alerts fire on a new control-plane event matching a filter. Resource Health and Service Health alerts are themselves activity log alerts.

Trap Treating Resource Health or Service Health as their own alert category: both are implemented as activity log alerts.

An action group is a named, reusable set of notifications (email, SMS, push, voice) and actions (webhook, secure webhook, Azure Function, Logic App, ITSM, automation runbook, Event Hub). Many alert rules reference the same action group, so the on-call list or remediation runbook is defined once and changed in one place rather than per rule.

Each fired alert has two independent states. The monitor condition is system-set: fired while the condition holds, then resolved when it clears (a stateful metric alert resolves after the condition is unmet for three consecutive checks). The user response, New, Acknowledged, or Closed, is set by you and never changes on its own. Alert instances are retained for 30 days.

Trap Assuming closing an alert (a user response) clears the underlying problem: the monitor condition only becomes resolved when the actual condition clears, independent of your response.

An alert processing rule modifies alerts as they fire, by filter and on a schedule, without touching any alert rule. Its two jobs are suppressing notifications (silence a resource group during planned maintenance: rules keep evaluating, only the noise is muted, and suppression lifts automatically) and adding an action group to many alerts at once. Use it instead of disabling or deleting the alert rules.

Trap Disabling each alert rule (or deleting the action group) to go quiet during maintenance: that loses the rule/breaks it for other rules; an alert processing rule suppresses temporarily and reverts on its own.

To create alert rules you need Monitoring Contributor (read on the target resource, write on the resource group holding the rule). Monitoring Reader can view alerts and read resources but cannot create rules. These are the two built-in roles supported at all Resource Manager scopes for alerting.

Azure Monitor Insights are Microsoft-curated monitoring experiences (preconfigured dashboards, workbooks, and sometimes alerts) built on the same metrics and Log Analytics data you could assemble yourself. The ones an administrator reaches for are VM Insights (VM and scale-set performance, processes, and a dependency map), Storage Insights (account performance, capacity, availability), Network Insights (health and metrics across network resources), and Container Insights (AKS workloads). Use an Insight when you want the page already built.

Azure Network Watcher is a regional service for monitoring and diagnosing the network of IaaS resources (VMs, VNets, gateways, load balancers); it is not designed for PaaS monitoring or web analytics. It is auto-enabled per region when you create a VNet, and there is exactly one Network Watcher instance per region per subscription.

Trap Choosing Network Watcher to monitor a PaaS service's own health: it targets IaaS network paths; for PaaS use that service's metrics, resource logs, and Insights.

IP flow verify checks whether a packet to or from a VM is allowed or denied based on the effective network security group rules, and it tells you which security rule made the decision. Reach for it when traffic is blocked and you need to identify the exact NSG rule responsible, rather than reading rules by hand.

Trap Using Next hop to find a blocking firewall rule: Next hop diagnoses routing (where traffic goes), while IP flow verify is the tool that names the allow/deny security rule.

Next hop returns the next hop type and IP for traffic from a VM to a destination, so it diagnoses routing problems such as a misconfigured user-defined route. Connection Troubleshoot tests whether a source can actually reach a destination right now, reporting latency and hops. Next hop answers 'where does this route send the traffic?'; Connection Troubleshoot answers 'can it connect at this moment?'.

Connection Monitor provides ongoing end-to-end connectivity monitoring between endpoints, with metrics and alerts over time. Connection Troubleshoot performs the same kind of check but only at a single point in time. When a scenario needs continuous monitoring with alerting, choose Connection Monitor; for a one-off diagnosis, Connection Troubleshoot.

Trap Using Connection Troubleshoot for ongoing connectivity SLA monitoring: it tests once at that moment; Connection Monitor is the continuous, alert-capable tool.

Network Watcher flow logs record IP traffic for traffic analysis. NSG flow logs are being retired: no new ones can be created after June 30, 2025, and they are fully retired on September 30, 2027. Virtual network (VNet) flow logs are the successor and address NSG flow log limitations, so new logging should use VNet flow logs.

Trap Creating new NSG flow logs for traffic logging: they are end-of-life (no new ones after June 30, 2025; retired September 30, 2027); use virtual network flow logs instead.

Before VM Insights can collect performance data it needs a Log Analytics workspace (data lands in the InsightsMetrics table), the Azure Monitor Agent on the VM, and a data collection rule (DCR) that tells the agent what to collect. The default VM Insights DCR gathers guest performance only: it does not collect Windows event logs or Syslog, so add a separate DCR for those. A VM Insights DCR must already exist before you assign an Azure Policy initiative to onboard VMs at scale.

Trap VM Insights does not collect event logs/Syslog out of the box; you create an additional DCR rather than editing the VM Insights one.

VM Insights has two features: Performance (Azure Monitor Agent only) and Map. The Map view of processes and application dependencies needs the Dependency Agent (the 'processes and dependencies' option) installed in addition to the Azure Monitor Agent. The portal's default data collection rule enables guest performance but leaves processes-and-dependencies (Map) disabled, so by default only the Azure Monitor Agent is installed and the Map view shows no data.

Trap Empty Map view with working Performance data means the Dependency Agent is missing, not a workspace or DCR problem.

In Log Analytics KQL, summarize aggregates rows and bin(TimeGenerated, 1h) buckets results into time intervals (e.g. hourly average per Computer). project selects, renames, or drops specific columns. render (e.g. render timechart) must be the last operator and turns query results into a visualization.

Trap bin() groups the time axis inside summarize: it is not the operator that draws the chart (that is render).

Azure Workbooks are the tool when you must blend Azure Monitor Logs, metrics, and Azure Resource Graph data in a single interactive report with embedded text, then let users filter via parameters (time range, resource selectors) and export to PDF. Azure Resource Graph is a supported data source for querying resource inventory and metadata (location, tags) across subscriptions to scope a report.

Trap Parameters (not editing the KQL) are what let consumers filter a workbook interactively.

Azure Monitor rate-limits action group notifications per recipient: email is capped at no more than 100 emails per hour to each email address (per region), and SMS and voice calls at no more than one notification every five minutes per phone number. Once the limit is hit, further notifications are dropped until the window expires, which is the usual reason an admin stops receiving alerts even though alerts are firing.

Trap Missing notifications with alerts clearly firing usually means rate limiting, not a wrong email/phone or an unsubscribe.

Azure Service Health reports subscription-wide event types including Service issues, Planned maintenance, Health advisories, Security advisories, and Billing updates. To be notified of planned maintenance you create a Service Health (activity log) alert plus an action group, and the action group region must be set to Global for Service Health alerts to work. Inactive Service Health events are retained in Health History for up to 90 days after they become inactive.

Trap An action group used for a Service Health alert must be in the Global region, not a specific Azure region.

Resource Health shows the health of an individual resource (such as one VM) and its reason type tells you whether unavailability was platform-initiated (Azure maintenance/host issue) or user-initiated (e.g. a manual stop or deallocate). A Resource Health status of Unknown means Azure has had no data about the resource for over 10 minutes, which commonly happens when a VM is deallocated.

Trap Service Health is for subscription-wide Azure incidents; Resource Health is the one that drills into a specific resource instance.