AZ-104 Study Guide

Microsoft Entra ID is the identity service behind every Azure subscription, and every user, group and service principal you assign access to lives there. Users are created in the cloud, synchronized from on-premises Active Directory, or invited from another organization. Groups are how you avoid assigning access one person at a time.

What you need to know

• Users come from three places: cloud-only accounts you create, accounts synchronized from on-premises Active Directory Domain Services with Microsoft Entra Connect, and guest users invited from another directory
• Security groups grant access to resources; Microsoft 365 groups also create a shared mailbox, calendar, SharePoint site and Teams team
• Membership is Assigned (you pick the members), Dynamic User or Dynamic Device (membership follows a rule written against attributes such as department or device OS)
• Dynamic membership requires a Microsoft Entra ID P1 license for each unique user
• Create and manage both in the Microsoft Entra admin center at entra.microsoft.com, with Microsoft Graph PowerShell, or with the Azure CLI

Exam tip: A Microsoft 365 group can use dynamic user membership but never dynamic device membership. Device rules are a security group feature, so watch for questions that mix the group type with the membership type.

Microsoft Learn resource: Learn about group types, membership types, and access management (opens in a new tab)

User and group properties are more than cosmetic: dynamic membership rules, group-based licensing and Conditional Access all read them. Getting department, usage location and job title right is what makes automation work later.

What you need to know

• Usage location is required before you can assign a license, because some services are not available in every country or region
• A user synchronized from on-premises Active Directory has most properties managed on-premises; you edit them in Active Directory, not in the cloud
• Group owners can manage membership of their own group without holding a directory role
• Properties such as department, country and employee ID are what dynamic membership rules query
• Bulk operations (bulk create, bulk invite, bulk delete) take a CSV template from the portal

Microsoft Learn resource: Create, configure, and manage identities (opens in a new tab)

Licenses can be assigned directly to a user or, more usefully, to a group so that everyone in the group inherits them. Group-based licensing means joiners and leavers are handled by membership rather than by an administrator remembering.

What you need to know

• A license can be assigned directly to a user or to a group, and a user can hold both kinds at once
• Group-based licensing reprocesses automatically when membership changes, so a new member is licensed without any further action
• A direct license must be removed directly; removing someone from the group only removes the license the group gave them
• Assignment fails when the usage location is missing, when there are not enough licenses, or when two assigned service plans conflict
• Combining group-based licensing with a dynamic group licenses people automatically from their attributes, and the dynamic group is the part that needs Microsoft Entra ID P1

Microsoft Learn resource: Assign or unassign licenses to a group in the Microsoft 365 admin center (opens in a new tab)

External users are people from another organization that you invite into your tenant with Microsoft Entra External ID B2B collaboration. They sign in with their own credentials and never get an account or a password in your directory.

What you need to know

• An invited external user appears in your directory with UserType set to Guest and authenticates against their home tenant
• Invitations go out by email or by a redemption link, and the guest accepts before the account becomes usable
• External collaboration settings control who may invite: everyone, only members and users in the Guest Inviter role, only administrators, or nobody
• The same settings restrict guest access to the directory and can allow or block specific domains
• A guest is assigned Azure roles exactly like a member, so a guest can hold Contributor on a subscription if you let them

Exam tip: Restricting who can invite guests is a tenant-wide setting in External Identities, not an Azure role. If a question asks how to stop ordinary users inviting guests, the answer is external collaboration settings.

Microsoft Learn resource: What is Microsoft Entra B2B collaboration? (opens in a new tab)

Self-service password reset lets users reset their own password or unlock their account without calling the help desk. You choose who it applies to, how many authentication methods they must pass, and whether the new password is written back to on-premises Active Directory.

What you need to know

• SSPR is enabled for None, a Selected group, or All users, and the usual rollout is a pilot group first
• You choose which methods are available (mobile app notification or code, email, mobile phone, office phone, security questions) and how many a user must pass, either one or two
• Password writeback sends the new password back to on-premises Active Directory and requires Microsoft Entra ID P1 or above
• Administrator accounts are held to a stricter, Microsoft-enforced two-method policy that you cannot relax
• You can require users to register for SSPR at next sign-in and to reconfirm their information on a schedule

Exam tip: Password writeback is the licensing trap. SSPR for cloud accounts is one thing; writing the password back to on-premises Active Directory is the feature that needs the premium license.

Microsoft Learn resource: How Microsoft Entra self-service password reset works (opens in a new tab)

Azure role-based access control is how you grant permissions to Azure resources. A role assignment is three things joined together: a security principal, a role definition, and a scope. Microsoft ships hundreds of built-in roles, and the exam cares most about a handful of them.

What you need to know

• A role definition lists Actions, NotActions, DataActions and NotDataActions; effective permissions are Actions minus NotActions
• Contributor is the role people reach for when they mean Owner, and the difference is exactly one thing: granting access to someone else
• Create a custom role when no built-in role fits, and store it as JSON with an AssignableScopes list
• A subscription supports up to 5,000 role assignments, which is a fixed limit and a good reason to assign to groups

Exam tip: If a scenario says someone must give other people access but must not be able to change the resources, the answer is User Access Administrator, not Owner.

Microsoft Learn resource: Azure built-in roles (opens in a new tab)

Scope is the set of resources an assignment applies to, and it runs from management group down to a single resource. Assignments are inherited downward, so the level you choose decides the blast radius.

What you need to know

• The four scopes, from broadest to narrowest: management group, subscription, resource group, resource
• Permissions are inherited: Reader at the subscription grants Reader on every resource group and resource inside it
• Azure RBAC is additive, so a user gets the union of everything assigned to them at every scope
• A deny assignment always beats a role assignment, and deny assignments are created by Azure (for example by deployment stacks or managed applications), never by you directly
• Assign roles to groups rather than to individual users, and assign at the narrowest scope that does the job

Exam tip: There is no way to subtract a permission with another role assignment. If someone has too much access, the fix is to remove the broader assignment, not to add a Reader assignment lower down.

Microsoft Learn resource: Understand scope for Azure RBAC (opens in a new tab)

Reading someone's effective access is a real exam skill: you are given a set of assignments at different scopes and asked what the person can actually do. The portal's Access control (IAM) blade is where you check it.

What you need to know

• Check access on the Access control (IAM) blade shows every role a chosen user, group or service principal has at that scope, inherited assignments included
• The Role assignments tab lists assignments at this scope and marks which are inherited from a parent
• Azure roles and Microsoft Entra roles are separate systems: Entra roles such as Global Administrator manage the directory, Azure roles manage resources
• A Global Administrator can elevate access to receive User Access Administrator at root scope, which is a temporary break-glass step and is logged
• Azure Policy and role assignments answer different questions: policy controls what a resource may look like, RBAC controls what a person may do

Exam tip: A Global Administrator does not automatically have access to Azure resources. This catches people out constantly, and the elevate access toggle in Microsoft Entra ID properties is the reason why.

Microsoft Learn resource: List Azure role assignments using the Azure portal (opens in a new tab)

Azure Policy enforces rules about the resources themselves: where they can be deployed, what SKUs are allowed, which tags they must carry. Where RBAC governs people, policy governs properties.

What you need to know

• A policy definition holds the condition and the effect; the effects include Audit, Deny, Append, Modify, AuditIfNotExists, DeployIfNotExists, DenyAction, Manual and Disabled
• An initiative (a policy set definition) groups definitions so you can assign a whole standard at once
• Assignments are made at a management group, subscription or resource group scope and are inherited downward, with an exclusion list for exceptions
• Existing resources are evaluated for compliance but are not changed; bringing them into line takes a remediation task
• Remediation works with the DeployIfNotExists and Modify effects, and the assignment needs a managed identity with rights to make the change

Exam tip: Deny stops a non-compliant resource from being created; it does not delete a resource that already exists. When a question asks how to fix resources that are already deployed, the answer is a remediation task.

Microsoft Learn resource: Azure Policy definitions effect basics (opens in a new tab)

A resource lock protects a resource from accidental change or deletion, and it applies to everyone regardless of their role. It is the simplest guardrail in Azure and the one people forget they applied.

What you need to know

• Two lock types: CanNotDelete (read and modify, but not delete) and ReadOnly (read only, which is the stricter of the two)
• Locks can be set at subscription, resource group or resource scope, and child resources inherit them
• A lock applies to control plane operations, so it does not stop someone writing data into a locked storage account or database
• Creating or deleting a lock needs the Microsoft.Authorization/locks/* permission, which Owner and User Access Administrator hold
• ReadOnly has side effects worth knowing about: it blocks listing storage account keys, scaling an App Service plan, and starting a stopped virtual machine

Exam tip: When two locks apply, the most restrictive one wins, and inheritance means a ReadOnly lock on a resource group makes everything inside it read-only.

Microsoft Learn resource: Lock your resources to protect your infrastructure (opens in a new tab)

Tags are name and value pairs you attach to resources so you can group them for billing, ownership and automation. They are the cheapest governance you can apply and the first thing a cost report relies on.

What you need to know

• A resource, resource group or subscription can carry up to 50 tag name and value pairs
• Tag names are limited to 512 characters and values to 256, with a 128 character name limit on storage accounts
• Tags are not inherited: a tag on a resource group does not appear on the resources inside it
• Azure Policy is how you enforce tags at scale, with the Append and Modify effects adding or inheriting them and Deny refusing untagged resources
• Cost analysis and billing exports can group and filter by tag, which is the main reason to have a tagging standard at all

Exam tip: The missing inheritance is the classic trick question. If a scenario needs resources to carry their resource group's tag, the answer is an Azure Policy with the Modify effect plus a remediation task.

Microsoft Learn resource: Use tags to organize your Azure resources (opens in a new tab)

A resource group is a container that holds related resources and gives them a shared lifecycle, a shared access boundary and a shared policy scope. Every resource lives in exactly one resource group.

What you need to know

• A resource group has a location of its own, which stores the group's metadata; the resources inside it can be in other regions
• A resource belongs to one resource group at a time, and deleting the group deletes everything in it
• Resources can be moved between resource groups and subscriptions, which changes their resource ID; both source and target are locked during the move
• Not every resource type supports a move, and some must be moved together with their dependencies
• Role assignments, locks and policy assignments made on the group apply to everything inside it

Exam tip: Moving a resource does not move it to another region. A move between resource groups or subscriptions keeps the resource exactly where it is; changing region means redeploying or using Azure Resource Mover.

Microsoft Learn resource: Move resources to a new resource group or subscription (opens in a new tab)

A subscription is the billing and scale boundary in Azure. It links to one Microsoft Entra tenant for identity, carries its own quotas, and is where most role assignments and policy assignments land.

What you need to know

• Each subscription trusts exactly one Microsoft Entra directory, and one directory can hold many subscriptions
• Subscriptions have their own resource limits and quotas, and some quotas can be raised through a support request
• A subscription can be transferred to another billing account or another directory, and transferring to another directory removes the existing Azure role assignments
• Management groups are how you apply policy and access across many subscriptions at once
• Cost Management scopes down to a subscription, which is the usual level for budgets and cost alerts

Microsoft Learn resource: Azure subscription and service limits, quotas, and constraints (opens in a new tab)

Cost management on the exam is three tools working together: cost analysis to see what you spent, budgets to warn you before you spend more, and Advisor to tell you what is wasteful.

What you need to know

• A budget is scoped to a subscription or a resource group and resets monthly, quarterly or annually
• A budget alert fires at a percentage threshold of actual or forecast spend, and it notifies only: nothing is shut down and no resource stops running
• Cost alerts cover budget alerts, credit alerts and department spending quota alerts
• Azure Advisor groups recommendations into five categories: Reliability, Security, Performance, Cost and Operational excellence
• Typical Advisor cost recommendations are resizing or shutting down underused virtual machines and buying reservations for steady workloads

Exam tip: If an answer option says a budget stops resources when the limit is hit, it is wrong. Budgets send notifications; only an automation you build yourself (for example an action group calling a runbook) can act on them.

Microsoft Learn resource: Tutorial: Create and manage budgets (opens in a new tab)

Management groups sit above subscriptions so that policy and access assignments apply to many subscriptions at once. Every directory gets a root management group that contains everything.

What you need to know

• A directory supports up to 10,000 management groups, and the tree can be up to six levels deep, not counting the root level or the subscription level
• Each management group and each subscription has exactly one parent, and the root management group cannot be moved or deleted
• Role assignments and policy assignments made on a management group are inherited by every subscription and resource below it
• Only a Global Administrator can elevate access to manage the root management group, and no one has access to it by default
• The usual pattern is a small tree that mirrors how the organization is governed, for example production and non-production

Microsoft Learn resource: What are Azure management groups? (opens in a new tab)

By default a storage account accepts requests from any network, and authorization alone decides who gets in. The firewall narrows that to the networks you name, and it is the first thing to turn on for an account holding anything sensitive.

What you need to know

• Public network access is Enabled from all networks, Enabled from selected virtual networks and IP addresses, or Disabled
• Selected networks are allowed by subnet (through a service endpoint), by public IP address or CIDR range, or by resource instance
• Private IP ranges cannot be used in IP rules, because the rules match the source public address
• The Allow Azure services on the trusted services list to access this storage account exception lets services such as Azure Backup and Azure Monitor through
• A private endpoint gives the account a private IP in your virtual network and reaches it regardless of the firewall rules

Exam tip: Turning the firewall on can lock you out of the portal's data view, because your own browser is on the internet. Add your client IP address as an exception before you switch the default action to deny.

Microsoft Learn resource: Azure Storage firewall rules and network access control (opens in a new tab)

A shared access signature is a signed URL that grants limited access to storage without handing over an account key. You choose the services, the permissions, the time window and optionally the allowed IP range, and the signature carries all of it.

The three SAS types:

1. User delegation SAS: signed with Microsoft Entra credentials rather than an account key, scoped to Blob Storage, and the type Microsoft recommends because it is tied to an identity and can be revoked by revoking the delegation key
2. Service SAS: signed with an account key and scoped to one service, and the only type a stored access policy can govern
3. Account SAS: signed with an account key and able to span several services and account-level operations, which makes it the broadest and the riskiest

Exam tip: Anyone holding the account key can mint a service or account SAS, so rotating the key is what invalidates every signature made with it. A user delegation SAS survives a key rotation, because no key signed it.

Microsoft Learn resource: Grant limited access to Azure Storage resources using shared access signatures (SAS) (opens in a new tab)

A stored access policy is defined on a container, file share, queue or table and holds the start time, expiry and permissions for the signatures that reference it. It exists so you can change or revoke a signature after you have handed it out.

What you need to know

• A stored access policy applies to a service SAS only, never to an account SAS or a user delegation SAS
• Changing the policy changes every signature bound to it, and deleting the policy revokes them immediately
• Up to five stored access policies can exist on a single container or share
• A service SAS can take its start time, expiry and permissions from the policy, supply them itself, or split them between the two, but never define the same field twice
• Without a stored access policy, the only way to revoke a service SAS early is to rotate the account key that signed it

Microsoft Learn resource: Define a stored access policy (opens in a new tab)

Every storage account is created with two 512-bit access keys, and either one grants full control of the account and everything in it. Two keys exist so you can rotate one while applications are still using the other.

What you need to know

• Key rotation is the two-step dance: move applications to key2, regenerate key1, move applications back, regenerate key2
• Regenerating a key immediately breaks every connection string and every service or account SAS signed with it
• Access keys can be stored in Azure Key Vault so applications fetch them rather than holding them in configuration
• Microsoft recommends authorizing with Microsoft Entra ID instead, and you can disable shared key authorization on the account entirely
• Reading the keys needs the Storage Account Key Operator Service Role or a role carrying listKeys, and a ReadOnly lock blocks listing them

Exam tip: Assigning a data role such as Storage Blob Data Contributor grants access to the data without ever exposing the account keys. That is the answer to "least privilege" storage questions.

Microsoft Learn resource: Manage account access keys (opens in a new tab)

Identity-based access lets users mount an SMB file share with their own domain identity, so NTFS permissions on files and folders work the way they do on a file server. Without it, everyone connects with the storage account key and has the same rights.

What you need to know

• Three identity sources are supported: on-premises Active Directory Domain Services, Microsoft Entra Domain Services, and Microsoft Entra Kerberos
• Access is evaluated twice: a share-level Azure role decides whether you can mount the share, then Windows ACLs decide what you can do inside it
• The share-level roles are Storage File Data SMB Share Reader, Contributor and Elevated Contributor, the last of which can change ACLs
• The client must be domain-joined to the same identity source, except with Microsoft Entra Kerberos, which works for Microsoft Entra joined devices
• The storage account key stays a full-control back door, so restrict who can read it

Exam tip: Share-level permission and file-level permission are two different checks. A user with the right role who still cannot open a folder is being stopped by the NTFS ACL, not by Azure.

Microsoft Learn resource: Overview of Azure Files identity-based authentication options for SMB access (opens in a new tab)

The storage account is the namespace that holds blobs, files, queues and tables, and the choices you make when you create it decide which services and features you get. Several of them cannot be changed afterwards.

What you need to know

• The account name is globally unique, 3 to 24 lower case letters and numbers, and forms the endpoint yourname.blob.core.windows.net
• Region, account kind and performance tier are set at creation and cannot be changed later; redundancy and access tier can be changed afterwards
• Standard general-purpose v2 is the default answer unless the question asks for premium latency or a specific workload
• Minimum TLS version, shared key access, secure transfer and public blob access are all account-level settings worth checking

Microsoft Learn resource: Storage account overview (opens in a new tab)

Redundancy decides how many copies of your data exist and where. Two questions settle every redundancy exam item: does it need to survive a datacenter failure, and does it need to survive a region failure.

What you need to know

• Read access to the secondary region is an extra: RA-GRS and RA-GZRS expose a read-only secondary endpoint whose host name ends in -secondary
• Without the read access variants, the secondary copy is unreadable until a failover happens
• Failover is either Microsoft-managed, for a genuine region-wide disaster, or customer-managed, which you initiate yourself
• Replication to the secondary region is asynchronous, so a region failure can lose the most recent writes

Exam tip: Read the requirement for the words "availability zone" and "region". Zone redundancy is ZRS, region redundancy is GRS, and needing to read the second copy is what makes it RA-GRS.

Microsoft Learn resource: Azure Storage redundancy (opens in a new tab)

Object replication copies block blobs from a container in one storage account to a container in another, asynchronously. It is how you put data close to the consumers that read it, or keep a processed copy separate from the raw one.

What you need to know

• A replication policy names a source account and container, a destination account and container, and up to ten rules
• Blob versioning must be on for both the source and the destination account, and the change feed must be on for the source
• Only block blobs are replicated; page blobs, append blobs and snapshots are not
• A rule can filter by blob name prefix and can copy only blobs created after a chosen time, or all existing blobs
• The destination container is read-only for replicated blobs, and replication runs asynchronously with no defined completion time

Exam tip: Object replication is not a backup and not a redundancy option. It moves blobs between accounts you own; GRS is what protects you from losing a region.

Microsoft Learn resource: Object replication for block blobs (opens in a new tab)

All data written to Azure Storage is encrypted at rest with 256-bit AES, and that cannot be turned off. The configuration choices are about who holds the key and whether you want a second layer.

What you need to know

• Storage Service Encryption is on by default, uses Microsoft-managed keys and costs nothing
• Customer-managed keys live in Azure Key Vault or Managed HSM, and the storage account needs an identity with permission to use them
• Customer-managed keys cover blobs and files; queues and tables need the account to be created with a customer-managed key scope
• Infrastructure encryption adds a second, independent layer of encryption and can only be enabled when the account is created
• Encryption scopes let a single container or an individual blob use a different key from the rest of the account

Exam tip: Infrastructure encryption is a create-time decision. If a question asks how to add double encryption to an existing account, the answer is to create a new account and move the data.

Microsoft Learn resource: Azure Storage encryption for data at rest (opens in a new tab)

Two tools show up in every data movement question. Storage Explorer is the desktop application with a tree view, and AzCopy is the command line tool that does the heavy lifting.

What you need to know

• Azure Storage Explorer is a free cross-platform desktop app for browsing blobs, files, queues and tables, and it uses AzCopy underneath for transfers
• AzCopy is a command line tool for copying to, from and between storage accounts, and it is the right answer for bulk or scripted transfers
• Both authorize with Microsoft Entra ID or with a SAS token, and Storage Explorer can also attach an account with a key or a connection string
• A server-to-server copy with azcopy copy moves data directly between accounts without passing through your machine
• azcopy sync makes a destination match a source, which is the one to use for repeat runs rather than a full copy

Microsoft Learn resource: Get started with AzCopy (opens in a new tab)

Azure Files gives you a fully managed SMB or NFS file share in the cloud that servers and workstations mount with a drive letter or a mount point. It is the lift-and-shift answer for an old file server.

What you need to know

• SMB shares are reachable over TCP port 445, which many internet providers block outbound, so a VPN, ExpressRoute or private endpoint is often needed
• SMB 2.1, 3.0 and 3.1.1 are supported, and 3.1.1 is the one to use
• A share can grow to 100 TiB when large file shares are enabled on a standard account, against 5 TiB without it
• Standard shares are billed on data stored and transactions; premium shares are provisioned with a fixed size and performance
• NFS shares require a premium file share account and use host-based rather than identity-based access

Exam tip: Port 445 blocked outbound is the most common reason a mount fails from home or from a branch office. Test it before you start looking at permissions.

Microsoft Learn resource: Planning for an Azure Files deployment (opens in a new tab)

A container is the folder-like grouping inside Blob Storage that holds blobs and sets their public access level. Blob Storage itself holds three blob types, and the exam expects you to know which is which.

What you need to know

• Block blobs hold files and objects, append blobs are optimized for logging, and page blobs back virtual machine disks
• Public access is Private (no anonymous access), Blob (anonymous read of blobs), or Container (anonymous read of blobs and the container listing)
• Anonymous access has to be allowed on the storage account before a container can be set to Blob or Container
• A container name is 3 to 63 lower case letters, numbers and hyphens, and $root is a reserved name
• Containers cannot be nested; the slashes in a blob name give the appearance of folders through a prefix

Exam tip: Setting a container to Blob allows reading a blob whose exact URL you know; Container additionally allows listing what is inside. Nothing about either level allows writing.

Microsoft Learn resource: Manage blob containers using the Azure portal (opens in a new tab)

Access tiers trade retrieval cost against storage cost. Hot data is cheap to read and expensive to keep; archive is the opposite, and it is offline.

What you need to know

• The account default tier can be Hot, Cool or Cold; archive is set per blob only and is never an account default
• Deleting or moving a blob before its minimum retention period charges an early deletion fee for the remaining days
• Rehydrating an archived blob takes up to 15 hours at Standard priority, or under an hour at High priority for objects under 10 GB
• Rehydration either changes the blob's tier in place or copies it to a new blob in an online tier

Exam tip: An archived blob cannot be read, and it cannot be overwritten. Any scenario that needs the data back within minutes rules archive out no matter how good the price looks.

Microsoft Learn resource: Access tiers for blob data (opens in a new tab)

Soft delete keeps deleted data recoverable for a retention period instead of removing it immediately. It is enabled per storage account, and it is the cheapest protection against a mistaken delete.

What you need to know

• Blob soft delete and container soft delete are separate settings, each with a retention period of 1 to 365 days
• Container soft delete defaults to 7 days when you enable it in the portal
• Container soft delete restores the container and its contents; it cannot restore individual blobs inside a deleted container
• Soft delete protects against deletes and overwrites, and an overwritten blob leaves a soft-deleted snapshot of the previous content
• Deleting the storage account itself is not covered: that is a separate account recovery within 14 days, and only for accounts with no other account of the same name

Exam tip: Enable container soft delete as well as blob soft delete. Blob soft delete on its own does not save you when somebody deletes the whole container.

Microsoft Learn resource: Soft delete for blobs (opens in a new tab)

Azure Files has its own recovery features, separate from the blob ones. Share snapshots are point-in-time read-only copies, and soft delete keeps a deleted share recoverable.

What you need to know

• A share snapshot is a read-only, point-in-time copy of an entire file share, taken manually, by Azure Backup, or by script
• Snapshots are incremental: only the blocks changed since the previous snapshot are stored, so they are cheap to keep
• Users can restore previous versions of a file from a snapshot through the Previous Versions tab in Windows Explorer
• Soft delete for file shares keeps a deleted share for 1 to 365 days, with a default of 7 days
• Deleting a share with snapshots requires deleting the snapshots too, or using the option to delete the share and its snapshots together

Microsoft Learn resource: Use share snapshots with Azure Files (opens in a new tab)

Lifecycle management is a rule-based policy on the storage account that moves blobs to cooler tiers or deletes them as they age. It is how tiering happens without anyone remembering to do it.

What you need to know

• A policy is JSON with up to 100 rules, each holding a filter set and a set of actions
• Filters narrow by blob type, by name prefix and by blob index tag; with no filter the rule applies to the whole account
• Actions are tierToCool, tierToCold, tierToArchive, delete and enableAutoTierToHotFromCool, triggered by days since creation, since last modification or since last access
• The policy is evaluated once every 24 hours, so a new rule is not applied the moment you save it
• Tiering actions apply to block blobs; append blobs support delete only, and page blobs are not covered

Exam tip: Last access time tracking has to be turned on before a rule can use days since last access. Without it, the rule never matches anything.

Microsoft Learn resource: Azure Blob Storage lifecycle management overview (opens in a new tab)

Blob versioning automatically keeps the previous state of a blob every time it is modified or deleted. Where soft delete gives you a grace period, versioning gives you a history.

What you need to know

• Versioning is enabled per storage account and applies to every container in it from that moment on
• Each write creates a new version with its own version ID; the current version is the one served by the blob URL
• Versions are retained until you delete them, so pair versioning with a lifecycle rule that deletes old versions or costs will grow
• Object replication requires versioning on both accounts, which is the most common reason to enable it
• Versioning and snapshots can coexist, but versioning is automatic where a snapshot is something you ask for

Microsoft Learn resource: Blob versioning (opens in a new tab)

The exam shows you template code and asks what it does, so reading matters more than writing. An ARM template is JSON; a Bicep file is a friendlier language that compiles down to the same JSON.

What you need to know

• An ARM template's top-level elements are $schema, contentVersion, parameters, variables, functions, resources and outputs, of which schema, contentVersion and resources are required
• Parameters are the values supplied at deployment time; variables are values built inside the template; outputs are values returned after deployment
• A resource is identified by its type and apiVersion, and dependsOn tells Resource Manager what must exist first
• Bicep says the same thing with far less punctuation, and param, var, resource and output map onto the JSON elements one for one
• Bicep infers most dependencies from symbolic references, so an explicit dependsOn is rarely needed

Exam tip: Read the dependsOn entries first when a question asks about deployment order. Without them, Resource Manager creates resources in parallel.

Microsoft Learn resource: Understand the structure and syntax of ARM templates (opens in a new tab)

Most template work in real life is editing something that already exists: adding a resource, parameterizing a hard-coded value, or changing a SKU. The structure tells you where each change belongs.

What you need to know

• Move a hard-coded value into parameters when the caller should choose it, and into variables when the template should
• allowedValues restricts a parameter to a list, and defaultValue makes it optional
• Template functions such as resourceGroup().location, concat(), parameters() and reference() are what keep a template portable
• A parameter file (azuredeploy.parameters.json) supplies the values, so the same template deploys to several environments
• Adding a resource means adding an object to the resources array with the right type and apiVersion, and a dependsOn if it needs another resource first

Microsoft Learn resource: Deploy Azure infrastructure by using JSON ARM templates (opens in a new tab)

Bicep is the current recommendation for new infrastructure as code on Azure, and the exam treats it as a peer of JSON rather than a novelty. The edits are the same edits, in a cleaner syntax.

What you need to know

• param name string = 'default' declares a parameter with a default; @allowed([...]) and @description('...') are decorators on it
• A resource is declared as resource symbolicName 'type@apiVersion' = { ... }, and other resources refer to it by its symbolic name
• Referring to a symbolic name creates an implicit dependency, which replaces most dependsOn entries
• Modules let one Bicep file call another, which is how larger deployments are broken up
• Bicep needs no state file: Azure Resource Manager holds the state, and a redeployment reconciles the difference

Microsoft Learn resource: What is Bicep? (opens in a new tab)

Templates are deployed to a scope: usually a resource group, sometimes a subscription, management group or tenant. The deployment mode decides what happens to resources the template does not mention.

What you need to know

• Incremental mode is the default: resources in the template are created or updated, and resources already in the group are left alone
• Complete mode deletes any resource in the resource group that is not in the template
• The CLI command is az deployment group create, and the PowerShell equivalent is New-AzResourceGroupDeployment
• Deployments are idempotent, so running the same template twice leaves the same result
• A what-if operation previews the changes before you commit to them, and validation checks the template without deploying

Exam tip: Complete mode plus an incomplete template is how people delete production. If a question describes resources disappearing after a deployment, the mode is the answer.

Microsoft Learn resource: Azure Resource Manager deployment modes (opens in a new tab)

Exporting turns what already exists into code, which is the usual starting point when nobody wrote a template in the first place. Decompiling turns that JSON into Bicep.

What you need to know

• Export template on a resource group generates a template from the current resources, and the portal offers a Bicep view of the same result
• Export template on a deployment under the Deployments blade returns the template that was actually run, which is usually cleaner
• An exported template often needs editing: hard-coded names, missing dependencies and unsupported resource types are normal
• az bicep decompile --file main.json converts JSON to Bicep, and az bicep build converts Bicep back to JSON
• A decompiled file is a starting point rather than a finished one, and Microsoft says as much

Microsoft Learn resource: Decompile ARM template JSON to Bicep (opens in a new tab)

Creating a virtual machine looks like one action but is really several resources created together: the VM, a network interface, a disk, usually a public IP and a network security group. Knowing which is which matters when you delete one later.

What you need to know

• A VM needs a region, a size, an image, an administrator credential, a virtual network and subnet, and at least one disk
• The network interface, public IP address, disks and NSG are separate resources, and deleting the VM does not automatically delete all of them unless you ticked the delete-with-VM options
• Windows authenticates with a username and password; Linux prefers an SSH public key
• Generation 2 images are required for Trusted Launch, larger memory sizes and several security features
• A VM can be created from the portal, a template, the CLI (az vm create), PowerShell, or an image in a Compute Gallery

Exam tip: A stopped VM in the portal is still allocated and still billed for compute. Only Stop (deallocate) releases the hardware and stops the compute charge; disks are billed either way.

Microsoft Learn resource: Introduction to Azure virtual machines (opens in a new tab)

Encryption at host encrypts the data on the VM's host machine before it ever reaches Azure Storage, covering the temporary disk and the disk caches that Azure Disk Encryption cannot reach.

What you need to know

• It encrypts the temporary disk, the OS and data disk caches, and the flow to the storage service, all at the host
• It is different from Azure Disk Encryption, which runs BitLocker or DM-Crypt inside the guest operating system
• The feature must be registered on the subscription (EncryptionAtHost) before it can be enabled
• Not every VM size supports it, and the VM must be deallocated to turn it on for an existing machine
• Encryption at host and Azure Disk Encryption cannot both be used on the same VM

Exam tip: End-to-end encryption including the temporary disk is the phrase that points at encryption at host. Azure Disk Encryption does not protect the temporary disk on all configurations.

Microsoft Learn resource: Use the Azure portal to enable end-to-end encryption using encryption at host (opens in a new tab)

Three different moves, three different tools. The exam separates them, and picking the wrong one is a common mistake.

What you need to know

• Moving between resource groups or subscriptions is a resource move: the VM stays where it is physically, and its resource ID changes
• Both the source and the target resource group are locked while the move runs, and no resource in either can be created, updated or deleted
• A VM must be moved with its dependencies: disks, network interface, public IP and availability set
• Moving to another region is a redeployment, and Microsoft recommends Azure Resource Mover; Azure Site Recovery does the same job through replication
• A subscription move does not carry role assignments across, so access has to be reapplied

Microsoft Learn resource: Move resources to a new resource group or subscription (opens in a new tab)

The size decides the vCPUs, the memory, the disk throughput and how many data disks and network interfaces a VM can have. Sizes are grouped into families by what they are good at.

What you need to know

• The families to recognize: B burstable, D general purpose, E memory optimized, F compute optimized, L storage optimized, N GPU, H high performance computing
• A letter s in the size name means premium storage is supported, and a d means the size includes a local temporary disk
• Resizing is done from the portal, CLI or PowerShell, and a running VM can be resized only to a size available on the hardware cluster it is on
• If the size you want is not available on the current cluster, deallocate the VM first and the resize will place it elsewhere
• Changing the size restarts the virtual machine, so it is never a no-downtime operation

Exam tip: The B-series banks credits while idle and spends them when busy. It is the right answer for workloads that sit quiet most of the day, and the wrong answer for anything with sustained CPU.

Microsoft Learn resource: Change the size of a virtual machine (opens in a new tab)

Every VM has an OS disk and usually a temporary disk, and data disks are attached separately. The disk type sets the performance and most of the cost.

What you need to know

• The temporary disk is local to the host, is not persistent, and loses its contents on a deallocation, a redeploy or a host maintenance event
• Not all VM sizes include a temporary disk: the sizes with a d in the name do
• Host caching is None, ReadOnly or ReadWrite, with ReadWrite the default for the OS disk and ReadOnly for data disks; use None for write-heavy data disks
• Disks can be expanded but never shrunk, and expanding usually requires the VM to be deallocated

Exam tip: Never put anything you want to keep on the temporary disk, and never assume D: on Windows or /dev/sdb on Linux is a data disk. That is the temporary disk on most sizes.

Microsoft Learn resource: Azure managed disk types (opens in a new tab)

Availability sets protect against failures inside a datacenter; availability zones protect against the loss of a whole datacenter. The service level agreement attached to each is what the exam usually tests.

What you need to know

• An availability set spreads VMs across up to 3 fault domains (separate racks, power and network) and up to 20 update domains (separate maintenance groups)
• A region that supports zones has a minimum of three separate zones, each with independent power, cooling and networking
• An availability set is chosen at creation and cannot be added to an existing VM, and a VM cannot be in both a set and a zone
• A zone-redundant resource such as a Standard Load Balancer or a zone-redundant public IP is needed in front of zonal VMs for the design to hold up

Exam tip: Learn the three SLA numbers. A question that says "must meet a 99.99% availability requirement" is asking for availability zones, and nothing else will do.

Microsoft Learn resource: Availability sets overview (opens in a new tab)

A scale set manages a group of identical virtual machines as one resource, adding and removing instances as demand changes. It is how you get elasticity out of infrastructure as a service.

What you need to know

• Two orchestration modes: Flexible, which Microsoft recommends for new deployments and which manages VMs as standard VM resources, and Uniform, the older identical-instance model
• Scaling is manual (set the instance count yourself) or automatic (rules based on a metric such as CPU percentage)
• An autoscale rule has a metric, a threshold, a duration, a cool-down period and an action to add or remove instances, and you set minimum, maximum and default counts
• Upgrade policy is Automatic, Rolling or Manual, and it decides how a change to the model reaches the existing instances
• A scale set sits behind a load balancer or an application gateway, and it can spread instances across availability zones

Exam tip: Write the scale-in rule as the mirror of the scale-out rule and always set a cool-down. Rules that fight each other produce flapping, which is a favourite scenario in exam questions.

Microsoft Learn resource: Orchestration modes for Virtual Machine Scale Sets in Azure (opens in a new tab)

Azure Container Registry is your private registry for container images and other OCI artifacts. The SKU decides the storage, the throughput and which of the enterprise features you get.

What you need to know

• Three SKUs: Basic for learning and small workloads, Standard for most production use with more storage and throughput, and Premium for the largest workloads
• Geo-replication is Premium only, and so are private endpoints, content trust, customer-managed keys and connected registries
• The registry name is globally unique and gives you the login server yourname.azurecr.io
• Authentication is by Microsoft Entra identity (az acr login), a service principal, or the admin account, which is off by default and meant only for testing
• ACR Tasks build images in Azure, and a base image update can trigger an automatic rebuild

Exam tip: If a question needs the same image pulled quickly from several regions, the answer is geo-replication, and that means the Premium SKU.

Microsoft Learn resource: Azure Container Registry SKU features and limits (opens in a new tab)

Azure Container Instances runs a container without any cluster or orchestrator, billed per second. It is the fastest way to get a container running and the right answer for short, simple or bursty jobs.

What you need to know

• Containers are deployed in a container group, which shares a lifecycle, a network, an IP address and storage across its containers
• Restart policies are Always (the default), Never and OnFailure, and OnFailure is the one for a task that should run to completion
• An Azure Files share can be mounted into a container group to give it persistent storage
• A container group can be given a public IP with a DNS name label, or deployed into a virtual network subnet
• Container Instances has no autoscaling and no load balancing of its own, which is what pushes larger workloads to Container Apps or AKS

Exam tip: OnFailure with a container that exits cleanly is how you run a batch job once. Leave the policy at Always and the job restarts forever.

Microsoft Learn resource: Container groups in Azure Container Instances (opens in a new tab)

Azure Container Apps is a serverless container platform built on Kubernetes, with the cluster hidden from you. It adds the scaling, revisions and ingress that Container Instances lacks.

What you need to know

• Container apps live in an environment, which is the secure boundary that apps inside it share, along with a virtual network and a Log Analytics workspace
• Scaling is driven by KEDA rules of three kinds: HTTP, TCP and custom (a queue length, an event count, or a CPU or memory threshold)
• An app can scale to zero when idle, which is where most of the cost saving comes from
• Revisions are immutable versions of an app, and traffic can be split across them for blue-green or canary releases
• Ingress can be external (reachable from the internet) or internal (reachable only inside the environment)

Microsoft Learn resource: Set scaling rules in Azure Container Apps (opens in a new tab)

Sizing containers is about the CPU and memory you request; scaling is about how many copies run. The two services answer those questions very differently.

What you need to know

• In Container Instances you set CPU cores and memory per container, and the container group's total is the sum of its containers
• Container Instances has fixed sizing and no autoscale: more capacity means deploying another container group
• In Container Apps you set CPU and memory per replica in fixed allowed combinations, and the scale rule sets minimum and maximum replicas
• Minimum replicas of 0 allows scale to zero; a minimum of 1 keeps an instance warm and removes the cold start
• Both services are billed on resources consumed over time, so an idle Container Apps app at zero replicas costs nothing for compute

Exam tip: A requirement that mentions traffic spikes, scaling to zero, or splitting traffic between versions is describing Container Apps. Container Instances is for a single fixed workload.

Microsoft Learn resource: Resource availability and quota limits for Azure Container Instances (opens in a new tab)

The App Service plan is the compute that your web apps run on: the region, the size of the instances and how many of them. Several apps can share one plan, and they share its resources.

What you need to know

• Tiers run Free and Shared (shared compute, quota-limited), Basic, Standard, Premium v3 and above (dedicated compute), and Isolated v2 (a dedicated App Service Environment)
• Free and Shared run on shared virtual machines, have CPU quotas and cannot use custom domains with TLS, deployment slots or autoscale
• Every app in a plan runs on every instance of the plan, so a busy app affects its neighbours
• The plan's operating system (Windows or Linux) and region are fixed when it is created
• Isolated v2 runs in an App Service Environment inside your own virtual network, which is the answer when full network isolation is required

Exam tip: Scaling is a property of the plan, not of the app. Moving one app to a bigger plan means moving it to a different plan, not resizing the app.

Microsoft Learn resource: What are Azure App Service plans? (opens in a new tab)

Scaling up changes the hardware each instance runs on; scaling out changes how many instances there are. Only one of them is automatic.

What you need to know

• Scale up means changing the plan's pricing tier, which gives more CPU, memory and features
• Scale out means adding instances, and the maximum instance count depends on the tier
• Manual scale-out is available from Basic, and autoscale requires Standard or higher
• An autoscale rule uses a metric, an operator and a threshold, with a scale-out and a scale-in rule plus a cool-down period
• Autoscale can also run on a schedule, which suits predictable business hours better than a metric does

Microsoft Learn resource: Get started with autoscale in Azure (opens in a new tab)

An App Service is the web app itself, running inside a plan. Most of the exam-relevant settings are on the app rather than the plan: runtime, configuration, identity and deployment.

What you need to know

• An app needs a globally unique name, which becomes yourname.azurewebsites.net, and a runtime stack such as .NET, Java, Node.js, Python or PHP, or a container image
• Application settings are injected as environment variables, and connection strings are held separately
• A managed identity lets the app reach Key Vault, Storage or SQL without any credential in configuration
• Deployment comes from Git, GitHub Actions, Azure DevOps, a ZIP push, an FTPS upload or a container registry
• App Service Diagnostics, the log stream and Kudu (the advanced tools console) are the built-in troubleshooting entry points

Microsoft Learn resource: Configure Azure App Service (opens in a new tab)

Serving a custom domain over HTTPS means a certificate bound to that hostname. App Service can issue one for you, import one from Key Vault, or take one you upload.

What you need to know

• Certificate options are an App Service managed certificate (free and renewed automatically, with restrictions on which domains qualify), an App Service certificate bought and stored in Key Vault, an import from Key Vault, or an uploaded PFX
• Binding a certificate requires Basic or higher, because custom domains are not available on Free or Shared
• SNI SSL serves many certificates from one IP address and is supported from the Basic tier; IP-based SSL dedicates an IP address to a certificate and needs Standard or higher
• An uploaded certificate must be a password-protected PFX with the full chain, using at least 2048-bit encryption
• HTTPS Only redirects HTTP requests to HTTPS, and the minimum TLS version is an app setting

Exam tip: IP-based SSL exists for old clients that do not send the server name during the handshake. Unless a question mentions legacy clients, SNI is the answer.

Microsoft Learn resource: Enable HTTPS for a custom domain in Azure App Service (opens in a new tab)

Pointing your own domain at a web app is two steps: prove you own the domain, then route traffic to the app. The record type depends on whether you are mapping the root or a subdomain.

What you need to know

• Custom domains require the Basic tier or higher; Free and Shared apps stay on azurewebsites.net
• A CNAME record maps a subdomain such as www to yourapp.azurewebsites.net, and this is the usual choice
• An A record maps a root (apex) domain to the app's inbound IP address, and it must be paired with a TXT verification record
• A TXT record named asuid followed by the subdomain, holding the app's custom domain verification ID, proves ownership
• DNS propagation is not instant, and a low time to live on the record before you change it makes the switch faster

Exam tip: A root domain cannot use a CNAME record, which is why apex mappings need an A record plus the asuid TXT record. Expect that pairing in a question.

Microsoft Learn resource: Set up an existing custom domain in Azure App Service (opens in a new tab)

App Service can back up the app's content, its configuration, and a connected database on a schedule, storing the result in a container in your own storage account.

What you need to know

• Backups require the Basic tier or higher, and Basic can back up and restore the production slot only
• The backup is written to a container in an Azure Storage account you nominate, in the same subscription
• Connected databases (Azure SQL Database, MySQL and PostgreSQL) can be included, and their connection strings must be configured on the app
• Custom backups are limited to 10 GB in total, of which up to 4 GB may be the database; automatic backups cover up to 30 GB
• A restore can go back over the same app or into a different app, and restoring overwrites the target

Microsoft Learn resource: Back up and restore your app in Azure App Service (opens in a new tab)

App Service networking splits neatly in two: features that control what the app can reach on its way out, and features that control who can reach the app on its way in.

What you need to know

• Virtual network integration is outbound only: it lets the app call resources inside a virtual network, and it needs a delegated subnet
• Private endpoints are inbound only: they give the app a private IP so it is reachable from the virtual network and not from the internet
• Access restrictions are inbound rules on the app's public endpoint, matching by IP range, service tag or virtual network, with a priority order and a final deny
• A service endpoint on the subnet plus an access restriction achieves a similar inbound result without a private endpoint
• Outbound traffic leaves from a set of addresses listed on the app, and a NAT gateway gives it a single predictable one

Exam tip: Integration and private endpoint are not two names for the same thing. Outbound calls into the network are integration; inbound access from the network is a private endpoint.

Microsoft Learn resource: App Service networking features (opens in a new tab)

A deployment slot is a live copy of the app with its own hostname, used to stage a release and then swap it into production with no downtime.

What you need to know

• Slots require Standard or higher: Standard allows 5 slots, Premium and Isolated allow 20, and Free, Shared and Basic have none
• A swap warms up the target slot first, then switches the routing, so users never hit a cold instance
• Settings marked deployment slot setting are sticky: they stay with the slot rather than travelling with the swap
• Sticky by default: publishing endpoints, custom domain names, TLS bindings, scale settings, access restrictions and Always On
• Traffic can be split by percentage to a slot for a canary release, and a swap can be rolled back by swapping again

Exam tip: Connection strings and app settings travel with the swap unless you tick the slot setting box. That box is what keeps the staging database pointing at staging.

Microsoft Learn resource: Set up staging environments in Azure App Service (opens in a new tab)

A virtual network is your private address space in Azure, and subnets divide it. Both the address space and the subnet sizes are decisions you live with, because resizing a subnet with resources in it is painful.

What you need to know

• A virtual network belongs to one region and one subscription, and its address space is one or more CIDR ranges
• Azure reserves 5 addresses in every subnet: the first four and the last one, so a /24 gives you 251 usable addresses
• The smallest supported subnet is a /29 and the largest is a /2
• Resources in different subnets of the same virtual network can talk to each other by default; no route or rule is needed
• Some services need a subnet of their own with a fixed name, such as AzureBastionSubnet and GatewaySubnet

Exam tip: Count the reserved addresses when a question asks how many virtual machines fit in a subnet. A /29 has 8 addresses and only 3 of them are usable.

Microsoft Learn resource: Configure virtual networks (opens in a new tab)

Peering connects two virtual networks so that resources in them communicate over the Microsoft backbone with private IP addresses, as if they were one network. It is low latency, high bandwidth and needs no gateway.

What you need to know

• Peering is non-transitive: if A peers with B and B peers with C, A cannot reach C without its own peering
• The address spaces of peered networks must not overlap
• Peering can be within a region or between regions, and cross-region peering is called global virtual network peering
• Peering is made of two links, one from each side, and it is not connected until both exist
• Allow gateway transit on one side plus use remote gateways on the other lets a peered network use the other network's VPN or ExpressRoute gateway

Exam tip: A hub and spoke design where spokes must reach each other needs either a full mesh of peerings or a network virtual appliance in the hub with user-defined routes. Peering alone will not do it.

Microsoft Learn resource: Virtual network peering (opens in a new tab)

A public IP address is a resource in its own right, and it can be attached to a virtual machine's network interface, a load balancer, a gateway or Azure Bastion. The Standard SKU is now the only one for new deployments.

What you need to know

• The Basic SKU retired on 30 September 2025, so Standard is what you deploy
• Standard public IPs are static only, are secure by default (inbound traffic is blocked unless a network security group allows it), and can be zone-redundant or pinned to one zone
• A public IP is allocated statically or dynamically, and a dynamic address changes when the resource is deallocated and started again
• A public IP prefix reserves a contiguous block of addresses so you know the range before you use it
• Deleting a virtual machine does not delete its public IP unless you asked for it to be deleted with the machine, and an orphaned public IP is still billed

Microsoft Learn resource: Public IP addresses in Azure (opens in a new tab)

Azure creates system routes so that everything in a virtual network can reach everything else and the internet. A user-defined route overrides them, which is how you push traffic through a firewall or an appliance.

What you need to know

• User-defined routes live in a route table, and a route table is associated with a subnet
• Next hop types you can choose: Virtual appliance, Virtual network gateway, Virtual network, Internet and None
• Selection is by longest prefix match first; when two routes have the same prefix, the order is user-defined route, then BGP route, then system route
• A next hop of None drops the traffic, which is how you block a destination at the routing layer
• Forcing traffic through an appliance also needs IP forwarding enabled on that appliance's network interface

Exam tip: A 0.0.0.0/0 user-defined route pointing at a virtual appliance sends all internet-bound traffic through it. This is the forced tunnelling pattern, and forgetting IP forwarding is why it silently fails.

Microsoft Learn resource: Virtual network traffic routing (opens in a new tab)

Connectivity questions on the exam are a process of elimination: routing, then rules, then name resolution, then the service itself. Azure gives you a tool for each step.

What you need to know

• IP flow verify answers whether a packet between two addresses and ports is allowed or denied, and names the rule that decided
• Next hop shows where Azure would send a packet from a given virtual machine to a given destination
• Effective security rules shows the combined network security group rules that apply to a network interface
• Connection troubleshoot tests a connection once and reports the hops and the failure point; Connection monitor watches it continuously
• Packet capture records traffic on a virtual machine and writes the capture to a storage account or to disk

Exam tip: When traffic is blocked, IP flow verify gives you the rule name in one step. Reading the rule set by eye is what makes this question slow.

Microsoft Learn resource: What is Azure Network Watcher? (opens in a new tab)

A network security group is a list of allow and deny rules that filter traffic to and from a subnet or a network interface. Application security groups let those rules name a group of machines instead of a list of addresses.

What you need to know

• Your own rules take priorities from 100 to 4096, and the lowest number wins; processing stops at the first match
• A rule matches on source, source port, destination, destination port and protocol, and the source or destination can be an IP range, a service tag or an application security group
• A network security group can be attached to a subnet, to a network interface, or to both, and both sets are evaluated
• An application security group groups network interfaces by name, so a rule can say "web servers to database servers" without any addresses in it

Exam tip: Inbound traffic is filtered by the subnet's rules first and then the interface's rules; outbound is the other way round. Traffic has to pass both.

Microsoft Learn resource: Network security groups (opens in a new tab)

When a subnet network security group and an interface network security group both apply, working out the result by hand is slow and error-prone. Azure calculates it for you.

What you need to know

• Effective security rules on a network interface shows every rule that applies, marked with the network security group it came from
• The view includes the default rules, so you can see which one is actually catching the traffic
• Rules are listed in priority order, and the first match decides the outcome
• Where a subnet rule and an interface rule disagree, traffic must be allowed by both to get through
• Effective security rules is a Network Watcher feature and is also reachable from the network interface's Settings blade

Microsoft Learn resource: Effective security rules overview (opens in a new tab)

Azure Bastion gives you RDP and SSH to virtual machines over TLS in the browser, without a public IP on the machine and without opening 3389 or 22 to the internet.

What you need to know

• Bastion needs a subnet named exactly AzureBastionSubnet, sized /26 or larger for the dedicated SKUs
• Four SKUs: Developer, Basic, Standard and Premium, and the Developer SKU is shared infrastructure that needs no dedicated subnet
• Standard adds host scaling, the native client, IP-based connection, custom ports, shareable links and file transfer; Premium adds session recording and a private-only deployment
• The target virtual machines need no public IP address and no inbound internet rule; Bastion reaches them on their private IP
• Bastion is deployed per virtual network and can serve peered networks

Exam tip: The subnet name is not a convention, it is a requirement. A subnet called Bastion or AzureBastion will not work.

Microsoft Learn resource: What is Azure Bastion? (opens in a new tab)

A service endpoint extends your virtual network identity to an Azure platform service, so the service can accept traffic from a subnet and refuse it from everywhere else. The traffic stays on the Azure backbone.

What you need to know

• A service endpoint is enabled on a subnet, for a named service such as Microsoft.Storage, Microsoft.Sql or Microsoft.KeyVault
• The platform service keeps its public IP address and its public name; nothing gains a private address
• The service's own firewall then allows that subnet, which is the half that actually restricts access
• Service endpoints are free, and they apply to the whole service namespace rather than to one resource
• They do not work from on-premises networks, because the source has to be a subnet in the virtual network

Microsoft Learn resource: Virtual network service endpoints (opens in a new tab)

A private endpoint puts a network interface with a private IP address from your subnet in front of a specific platform resource, using Azure Private Link. The service becomes part of your network.

What you need to know

• The private endpoint is a network interface in your subnet, and it maps to one specific resource, such as one storage account and one sub-resource (blob, file, table)
• DNS has to resolve the service's public hostname to the private IP, which is what the matching private DNS zone (for example privatelink.blob.core.windows.net) does
• It is reachable from on-premises over VPN or ExpressRoute, which service endpoints are not
• Public network access on the platform resource can then be disabled entirely
• Private endpoints are billed per hour and per gigabyte processed, where service endpoints are free

Exam tip: Private endpoint questions are usually DNS questions. If the name still resolves to the public address, the private DNS zone is missing or not linked to the virtual network.

Microsoft Learn resource: What is Azure Private Endpoint? (opens in a new tab)

Azure DNS hosts your domains on Microsoft's name servers. Public zones answer the internet; private zones answer only the virtual networks you link them to.

What you need to know

• A public zone is given four Azure name servers, and you delegate the domain at your registrar by pointing all four name server records at them
• Record types to know: A and AAAA for addresses, CNAME for an alias, MX for mail, TXT for verification, SRV for services, and NS and SOA which the zone creates itself
• A private DNS zone resolves names inside the virtual networks joined to it through a virtual network link
• Autoregistration on a link creates and removes A records for the virtual machines in that network automatically, and a network can autoregister to only one zone
• A zone name has to be unique inside its resource group, and a CNAME cannot sit at the apex of a zone

Microsoft Learn resource: Host your domain on Azure DNS (opens in a new tab)

Azure Load Balancer distributes traffic at layer 4 across a backend pool, inside your network or from the internet. It is the cheapest way to make a set of identical machines highly available.

What you need to know

• A public load balancer has a public frontend IP and balances internet traffic; an internal load balancer has a private frontend IP and balances traffic inside the network
• The pieces are a frontend IP configuration, a backend pool, a health probe and a load balancing rule, plus optional inbound NAT rules and outbound rules
• Load Balancer works at layer 4 on TCP and UDP; Application Gateway works at layer 7 and is the answer for URL path routing, SSL offload and a web application firewall
• The Basic SKU retired on 30 September 2025, so new deployments use Standard, which requires Standard public IPs and is secure by default
• Session persistence is None (five-tuple), Client IP (two-tuple) or Client IP and protocol (three-tuple)

Exam tip: Layer 4 or layer 7 settles most of these questions. Anything mentioning a URL path, a host header, cookies or a web application firewall is Application Gateway, not Load Balancer.

Microsoft Learn resource: What is Azure Load Balancer? (opens in a new tab)

When a load balancer sends nothing to the backend, the fault is nearly always the health probe, the rules or the backend itself. Work through them in that order.

What you need to know

• An instance that fails its health probe is taken out of rotation, so a probe pointing at the wrong port or path empties the pool
• The probe comes from the address 168.63.129.16, which the AllowAzureLoadBalancerInBound default rule permits; a deny rule above it breaks every probe
• A network security group on the backend must allow the probe port and the traffic port
• The backend pool has to contain healthy instances in the same virtual network, and a Standard load balancer needs Standard public IPs on its frontend
• Load Balancer metrics in Azure Monitor include health probe status and data path availability, which is the fastest way to see whether the pool is empty

Exam tip: Remember 168.63.129.16. It is the Azure platform address used for the health probe and for the DHCP and DNS communication a virtual machine depends on, and blocking it breaks more than load balancing.

Microsoft Learn resource: Troubleshoot Azure Load Balancer (opens in a new tab)

Metrics are lightweight numeric values collected at regular intervals, which makes them the right data for near real-time alerting and charts. Every Azure resource emits platform metrics with no configuration at all.

What you need to know

• Platform metrics are collected automatically and are retained for 93 days
• Each metric has dimensions you can split and filter by, such as a disk name or a status code
• Aggregations are Average, Minimum, Maximum, Sum and Count, and picking the wrong one is how a chart lies to you
• Metrics Explorer is where you build a chart, and a chart can be pinned to a dashboard or turned straight into an alert rule
• Guest-level metrics such as memory and disk space inside a virtual machine need the Azure Monitor agent and a data collection rule; they are not platform metrics

Exam tip: Memory usage is not a platform metric for a virtual machine. Azure sees the host, not the guest, so anything from inside the operating system needs the agent.

Microsoft Learn resource: Azure Monitor metrics overview (opens in a new tab)

Logs are records with different structures collected into a Log Analytics workspace. Nothing arrives there by itself: a diagnostic setting has to send it.

What you need to know

• A diagnostic setting on a resource sends its platform logs and metrics to a Log Analytics workspace, a storage account, an event hub, or a partner solution
• Each resource supports up to 5 diagnostic settings, and a setting can have more than one destination
• The activity log records control plane operations on a subscription and is kept for 90 days without any configuration; sending it to a workspace is how you keep it longer
• A Log Analytics workspace keeps data for 30 days by default, configurable up to 730 days interactive, with long-term retention beyond that
• A workspace has a region and a pricing model, and sending data across regions costs egress, so keep the workspace near the resources

Exam tip: No diagnostic setting means no logs. If a question says a resource's logs are missing from a workspace, this is almost always the answer.

Microsoft Learn resource: Diagnostic settings in Azure Monitor (opens in a new tab)

Log Analytics queries are written in Kusto Query Language. You do not need to write complex queries for the exam, but you do need to read one and say what it returns.

What you need to know

• A query starts with a table name and pipes it through operators: where to filter, project to choose columns, summarize to aggregate, sort to order, take to limit
• Common tables: Heartbeat for agent health, AzureActivity for the activity log, AzureDiagnostics and resource-specific tables for platform logs, Perf for performance counters
• The time range picker in the portal applies on top of the query, and ago(1h) inside the query does the same job explicitly
• A query can be saved, pinned to a workbook or dashboard, or used as the condition of a log search alert rule
• A workspace can be queried across resources and across workspaces with the workspace() and resource() functions

Microsoft Learn resource: Log queries in Azure Monitor (opens in a new tab)

An alert rule watches something and fires; an action group decides what happens when it does; an alert processing rule changes how those actions are applied. Keeping the three separate is the whole point.

What you need to know

• An alert rule has a scope (what is watched), a condition (the signal and threshold), an action group, and details such as severity and name
• Alert types: metric alerts (fast, near real time), log search alerts (a saved query on a schedule), and activity log alerts (a control plane event such as a deletion or a service health notice)
• Severity runs Sev 0 critical to Sev 4 verbose, and it drives nothing by itself other than how you triage
• An action group holds the notifications (email, SMS, push, voice) and the actions (webhook, Azure Function, Logic App, Automation runbook, ITSM, Event Hubs)
• An alert processing rule suppresses notifications during a maintenance window, or adds an action group to alerts at a scope, without editing the rules themselves

Exam tip: Suppressing alerts during planned maintenance is an alert processing rule, not a change to the alert rule and not disabling the action group.

Microsoft Learn resource: What are Azure Monitor alerts? (opens in a new tab)

Insights are prebuilt monitoring experiences: curated workbooks, charts and dependency maps for a particular resource type, so you are not building them yourself.

What you need to know

• VM insights shows performance and a dependency map of processes and connections, and it needs the Azure Monitor agent and a data collection rule
• Storage insights gives a dashboard of availability, latency, capacity and transactions across your storage accounts
• Network insights gives a topology view and health and metrics for network resources, with no agent required
• VM insights stores its data in a Log Analytics workspace, which is what makes the dependency map and the query experience possible
• Insights are reached from the resource's Monitoring section or from the Insights hub in Azure Monitor

Microsoft Learn resource: Overview of Azure Monitor Insights (opens in a new tab)

Network Watcher is a regional service that gives you a toolbox for monitoring and diagnosing a virtual network. Each tool answers one question, and knowing which tool answers which question is the exam skill.

Topology draws the resources in a virtual network and how they are connected, which is the quickest orientation when you inherit an environment.

Connection monitor tests reachability, latency and packet loss between endpoints continuously, across Azure, on-premises and the internet, and alerts when a connection degrades. The older Connection monitor (classic) has been retired, so new monitors use the current one.

IP flow verify tells you whether a specific packet would be allowed or denied, and names the network security group rule that decided.

Next hop shows where Azure would route a packet from a given virtual machine, which is how you confirm a user-defined route is doing what you think.

Effective security rules shows the combined network security group rules on a network interface, subnet rules and interface rules together.

Packet capture records traffic on a virtual machine, with filters, and saves it to a storage account or to the machine's disk for offline analysis.

Flow logs record the traffic that passes through a virtual network, and traffic analytics turns those logs into a picture of who is talking to whom. Note that NSG flow logs are being retired on 30 September 2027 and virtual network flow logs replace them.

Exam tip: Connection troubleshoot is the one-off test and Connection monitor is the continuous one. A question that mentions ongoing monitoring or alerting on a connection means Connection monitor.

Microsoft Learn resource: What is Azure Network Watcher? (opens in a new tab)

A Recovery Services vault is the container that holds backup data and recovery points for the classic Azure Backup workloads, and it is also where Azure Site Recovery keeps its configuration.

What you need to know

• A Recovery Services vault protects Azure virtual machines, Azure file shares, SQL Server and SAP HANA in Azure virtual machines, and on-premises machines through the MARS agent, MABS or DPM
• The vault's redundancy is set before the first backup: locally redundant, geo-redundant (the default) or zone-redundant, and it cannot be changed once anything is protected
• A vault is regional, and it can only protect resources in its own region, so a multi-region estate needs a vault per region
• Soft delete is on by default and keeps deleted backup data for 14 days, configurable from 14 up to 180 days
• The vault cannot be deleted while it still contains protected items or backup data

Exam tip: Redundancy is a one-way decision. If a question says a vault must be geo-redundant and it already has backups in it, the answer is a new vault.

Microsoft Learn resource: Recovery Services vaults overview (opens in a new tab)

The Backup vault is the newer container, and it holds the workloads that arrived after the Recovery Services vault. Knowing which vault takes which workload is the point of having two skills for it.

What you need to know

• A Backup vault protects Azure Blobs, Azure Managed Disks, Azure Database for PostgreSQL and Kubernetes services
• A Recovery Services vault protects Azure virtual machines, Azure file shares, SQL and SAP HANA in Azure virtual machines, and on-premises workloads
• Backup vaults use the Backup center experience, which gives one view across both vault types and all subscriptions
• Backup vault redundancy is also chosen at creation: locally redundant, zone-redundant or geo-redundant
• Both vault types support role-based access control, and the Backup Contributor, Backup Operator and Backup Reader roles keep backup duties separate from resource duties

Exam tip: Azure Files backup stays in a Recovery Services vault even though it feels like one of the newer workloads. Disks and blobs are the ones that go in a Backup vault.

Microsoft Learn resource: Backup vaults overview (opens in a new tab)

A backup policy is the schedule plus the retention: how often a backup runs and how long each copy is kept. One policy usually covers many machines.

What you need to know

• A virtual machine policy is either Standard, which backs up once a day, or Enhanced, which backs up several times a day and is required for Trusted Launch virtual machines
• Retention is set separately for daily, weekly, monthly and yearly recovery points, which is how the grandfather-father-son pattern is built
• Instant restore keeps local snapshots for fast restores: 1 to 5 days, default 2 on a Standard policy, and a longer range on an Enhanced one
• The policy lives in the vault, and changing it applies to every item using it
• Changing a policy to reduce retention shortens what is kept, so read the retention change warning before saving it

Microsoft Learn resource: Back up Azure VMs with an Enhanced policy (opens in a new tab)

Running a backup and, more importantly, getting data back out is the practical half of this skill. The restore options differ by workload.

What you need to know

• A virtual machine can be restored as a new virtual machine, by replacing the existing disks, or by restoring the disks only so you build the machine yourself
• File recovery mounts a recovery point as a drive on a machine so you can copy individual files out without restoring the whole machine
• Cross-region restore lets you restore into the paired region, and it requires a geo-redundant vault with that feature turned on
• Backup now runs a one-off backup outside the schedule, and its retention is set at the time you run it
• Backup reports and the Backup center jobs view are where you confirm a job succeeded, and failed jobs raise an alert you can route to an action group

Exam tip: Replacing the existing disks is the fastest way to recover a broken virtual machine in place, and it needs the original machine to still exist. If it was deleted, you restore a new one.

Microsoft Learn resource: About Azure Virtual Machine restore (opens in a new tab)

Where Backup protects data, Site Recovery protects the running service: it replicates whole virtual machines to a second region so they can be brought up there if the first region is lost.

What you need to know

• Azure to Azure replication is continuous, with crash-consistent recovery points every 5 minutes and app-consistent recovery points on a frequency you choose
• Enabling replication creates the target resources in the secondary region: a resource group, a virtual network, storage and a cache storage account
• A replication policy sets how long recovery points are retained and how often app-consistent snapshots are taken
• A recovery plan groups machines so they fail over in the right order, with manual actions or Automation runbooks between the groups
• Site Recovery is configured from the Recovery Services vault or from the virtual machine's Disaster recovery blade

Exam tip: Site Recovery is not a backup. It keeps a recent copy running elsewhere; it does not give you a copy of a file from three weeks ago. Questions that mention a retention period of months mean Azure Backup.

Microsoft Learn resource: About Site Recovery (opens in a new tab)

Failover is the part you rehearse. There are three kinds, and the exam expects you to know which one leaves production running and which one you use when the region is already gone.

What you need to know

• Test failover creates the machines in an isolated network without affecting production or replication, and it is the one to run regularly; you finish it with cleanup
• Planned failover is for an expected event: it shuts the source down cleanly first so nothing is lost
• Unplanned failover is for an outage that already happened, and it may lose the most recent changes
• After a failover you commit it, which discards the other recovery points and makes the failover final
• To go back, you reprotect so replication runs from the secondary to the primary, and then fail over again in that direction

Exam tip: Commit and reprotect are the two steps people forget. A failover is not finished when the machine boots in the second region.

Microsoft Learn resource: Run a test failover to Azure in Site Recovery (opens in a new tab)

Backups that fail quietly are the same as no backups. Azure Backup has both built-in alerting and a reporting layer on top of Log Analytics.

What you need to know

• Built-in Azure Monitor alerts for Azure Backup fire on failures, on deleted backup data and on other security-relevant events, and they are routed with an action group
• Backup reports are workbooks built on data the vault sends to a Log Analytics workspace, so a diagnostic setting on the vault is what turns them on
• Reports cover backup items, jobs, policies, storage consumed and optimization opportunities across vaults and subscriptions
• Data takes up to 24 hours to appear after the diagnostic setting is configured, so an empty report is usually a young one
• The Backup center gives a single jobs and alerts view across Recovery Services vaults and Backup vaults

Microsoft Learn resource: Configure reports for Azure Backup (opens in a new tab)