Last reviewed: May 2026
A scannable reference of architectural patterns the AZ-104 exam tests. Read top-to-bottom, or jump to a section.
Automatically manage security group membership based on user attributes (e.g., department).
Configure a Microsoft Entra ID security group with "Dynamic User" membership type and define an attribute-based rule.
Why: Attribute-based rules eliminate ongoing manual administration for user lifecycle changes. Requires Entra ID P1/P2.
Apply consistent governance (policies, RBAC) across multiple subscriptions from a single management point.
Create a management group, place subscriptions under it, and assign policies or RBAC roles at the management group scope.
Why: Policies and role assignments are inherited by all child subscriptions, enabling centralized and consistent governance.
Prevent resource deployment in unauthorized Azure regions across an entire subscription.
Assign the built-in "Allowed locations" Azure Policy with a `Deny` effect at the subscription scope.
Why: Policy provides preventative governance. RBAC controls actions, not deployment locations. Resource Locks prevent modification/deletion, not new deployments.
Grant permissions to manage VMs but not the underlying virtual network or user access.
Assign the built-in "Virtual Machine Contributor" role at the resource group or VM scope.
Why: This role provides specific VM management permissions (start, stop, reimage) without granting broad Contributor or Owner rights.
Require MFA when users access specific cloud apps (e.g., Azure portal) from outside the corporate network.
Create a Conditional Access policy with a "Named Location" for corporate IPs as an exclusion condition, and require MFA as a grant control.
Why: Excluding a trusted location is the key to bypassing MFA on the corporate network while enforcing it everywhere else.
Prevent deletion of critical resources, even by administrators with Owner roles.
Apply a `CanNotDelete` or `ReadOnly` resource lock on the resource or its resource group.
Why: Resource locks apply to all users, regardless of their RBAC role, providing the strongest protection against accidental deletion.
Automatically fix existing non-compliant resources identified by an Azure Policy (e.g., add a missing tag).
For policies with `Modify` or `DeployIfNotExists` effects, create a remediation task for the policy assignment.
Why: Remediation tasks trigger the policy's corrective action on all existing non-compliant resources, automating the process of bringing an environment into compliance.
Report on Azure costs broken down by department, project, or business unit.
Apply a consistent tag (e.g., "CostCenter") to all resources. Use Azure Cost Management to filter and group costs by that tag.
Why: Tags are the primary mechanism for custom cost allocation and reporting across different resource groups and subscriptions.
Grant administrators privileged roles only when needed, for a limited time, and with an approval workflow.
Use Microsoft Entra Privileged Identity Management (PIM). Make users eligible for roles and configure activation requirements.
Why: PIM enforces Just-In-Time (JIT) access, reducing the exposure of standing privileged accounts and providing a full audit trail.
Grant external partners access to Azure resources using their own corporate credentials.
Use Microsoft Entra B2B collaboration to invite partners as guest users to your tenant.
Why: B2B avoids creating and managing new credentials in your tenant; partners use their existing identity provider for authentication.
Minimize storage costs for long-term data (e.g., compliance archives) that is rarely accessed but must be retained.
Use a blob lifecycle management policy to automatically transition blobs from Hot/Cool to the Archive tier.
Why: The Archive tier has the lowest storage cost. Lifecycle rules automate the tiering process based on blob age or last access time.
Ensure read-access to storage data from a secondary region during a primary region outage.
Configure the storage account with Read-Access Geo-Redundant Storage (RA-GRS) or RA-GZRS.
Why: Standard GRS/GZRS replicates data but does not allow read access to the secondary until a failover. The "RA" prefix is required for continuous read access.
Ability to immediately revoke a set of Shared Access Signature (SAS) tokens for a specific container.
Create SAS tokens based on a stored access policy on the container. To revoke, modify or delete the policy.
Why: Modifying the stored access policy immediately invalidates all SAS tokens associated with it, providing a centralized revocation mechanism.
Synchronize an on-premises file server with an Azure file share while minimizing local disk space usage.
Deploy Azure File Sync and enable cloud tiering on the server endpoint.
Why: Cloud tiering keeps only frequently accessed ("hot") files cached locally, while less-used files are tiered to Azure, appearing as stubs on the local server.
Restrict network access to a storage account to specific VNet subnets and public IP addresses.
Enable the storage account firewall. Add virtual network rules for the subnets and IP address rules for the public IPs.
Why: The storage firewall provides network-level access control directly on the storage account's public endpoint, blocking all other traffic.
Protect blobs from accidental deletion by allowing recovery for a specified period.
Enable blob soft delete on the storage account and configure the retention period (e.g., 14 days).
Why: Soft delete retains deleted blobs for the configured period, allowing for simple undeletion. This is the first line of defense against accidental data loss.
Fulfill compliance requirements to store data in a non-erasable, non-modifiable (WORM) state for a fixed period.
Configure a time-based retention policy on a blob container and lock the policy.
Why: A locked time-based retention policy makes blobs immutable, preventing deletion or modification by anyone (including administrators) until the retention period expires.
Migrate a very large dataset (e.g., 50+ TB) to Azure Blob Storage when network bandwidth is limited.
Use the Azure Data Box physical appliance for an offline transfer.
Why: For large datasets, shipping a physical device is significantly faster than transferring data over a slow or saturated network connection.
Achieve a 99.99% SLA for VMs and protect an application against a single datacenter failure within a region.
Deploy multiple VM instances across different Availability Zones within the same region.
Why: Availability Zones are physically separate datacenters. Availability Sets only protect against rack-level failures within a single datacenter (99.95% SLA).
Deploy and test a new application version with live production traffic before a full release, with zero downtime.
Use an App Service deployment slot. Deploy to the slot, test, then perform a swap. Optionally use traffic routing for canary testing.
Why: Slots provide a full staging environment. The swap operation is a near-instantaneous redirect of traffic, ensuring zero downtime.
Run a short-lived, containerized batch job on a schedule, with minimal cost and no infrastructure management.
Use Azure Container Instances (ACI).
Why: ACI offers per-second billing and no cluster management overhead, making it the most cost-effective option for sporadic or short-lived container workloads.
Autoscale a workload with predictable daily peaks (e.g., business hours) while also handling unexpected spikes.
Configure VM Scale Set autoscale with both schedule-based rules and metric-based rules.
Why: Combining proactive (schedule) and reactive (metric) scaling provides the best balance of performance (ready before peak) and cost efficiency (scales down when idle).
Store container images for an Azure Kubernetes Service (AKS) cluster securely in a private registry with vulnerability scanning.
Use Azure Container Registry (ACR) Premium SKU and integrate it with AKS using a managed identity.
Why: ACR provides a private registry co-located in Azure. The Premium SKU includes vulnerability scanning. Managed identity provides secure, credential-less authentication from AKS to ACR.
Perform an OS or application update on all VMSS instances without causing application downtime.
Update the VMSS model (e.g., new image version) and use a Rolling upgrade policy.
Why: The Rolling policy updates instances in configurable batches, ensuring a subset of instances is always available to serve traffic throughout the update process.
Deploy a multi-container application (e.g., app + logging sidecar) that must share network and storage, without a full orchestrator.
Deploy the containers into a single Azure Container Instances (ACI) container group.
Why: A container group co-locates multiple containers, sharing a localhost network and volumes, perfect for sidecar patterns without the complexity of Kubernetes.
Increase the size of a VM's OS or data disk after it has been deployed.
Deallocate the VM, resize the disk resource in Azure, start the VM, then extend the partition inside the guest OS.
Why: Resizing the Azure disk only allocates more space. The guest OS must be instructed to use that new space by extending its file system partition.
Allow an App Service to securely access secrets from Azure Key Vault without storing credentials in the application.
Enable a system-assigned managed identity on the App Service and grant that identity `Get` and `List` permissions on the Key Vault secrets.
Why: Managed identity provides a credential-less authentication mechanism. The application can acquire an access token for Key Vault automatically, eliminating secrets management.
Organize a large, complex infrastructure-as-code deployment into smaller, reusable, and maintainable components.
Refactor the deployment into Bicep modules, with each module representing a logical unit (e.g., networking, compute), and orchestrate them from a main Bicep file.
Why: Modules promote code reuse, improve readability, and simplify management of complex infrastructure deployments.
Isolate application tiers (web, app, data) within a VNet, preventing direct communication between non-adjacent tiers.
Use a separate subnet for each tier and apply Network Security Groups (NSGs) to each subnet to control traffic flow.
Why: NSGs allow fine-grained, stateful filtering based on source/destination IP ranges (subnets), ports, and protocols, enabling network micro-segmentation.
Connect two VNets in different Azure regions privately over the Microsoft backbone network.
Configure Global VNet Peering between the two VNets.
Why: Global Peering is simpler, lower-latency, and higher-bandwidth than a VNet-to-VNet VPN connection. Traffic remains on the private Microsoft network.
VNet-A is peered to Hub-VNet, and Spoke-VNet is also peered to Hub-VNet. VMs in VNet-A cannot reach VMs in Spoke-VNet.
The cause is that VNet peering is non-transitive. To enable communication, peer VNet-A and Spoke-VNet directly or use an NVA in the Hub.
Why: Peering does not create a daisy-chain. Each VNet must be directly connected to communicate, unless routing through a Network Virtual Appliance is configured.
Establish a persistent, encrypted IPsec tunnel from an on-premises network to an Azure VNet over the public internet.
Deploy an Azure VPN Gateway in the VNet and configure a Site-to-Site (S2S) connection.
Why: This is the standard, secure, and reliable solution for hybrid connectivity between a single on-premises site and an Azure VNet.
An Azure Load Balancer continues to send traffic to an unhealthy backend VM, causing application timeouts.
Configure a health probe on the load balancer that accurately checks the health of the application on the backend VMs.
Why: The load balancer relies entirely on health probes to detect unhealthy instances. Without a correctly configured probe, it cannot remove failed VMs from the traffic rotation.
Route HTTP/S traffic to different backend server pools based on the URL path (e.g., /images/* vs /api/*).
Use Azure Application Gateway with path-based routing rules.
Why: Application Gateway is a Layer 7 load balancer that inspects HTTP requests and can make routing decisions based on URL paths. A standard Azure Load Balancer is Layer 4 and cannot.
VMs in a VNet with a custom DNS server cannot resolve hostnames in an Azure Private DNS Zone.
Configure the custom DNS server to conditionally forward queries for the private zone to the Azure-provided DNS resolver IP (168.63.129.16).
Why: When a custom DNS server is used, it bypasses Azure's internal DNS. The custom server must be taught how to resolve Azure-specific zones by forwarding requests to Azure DNS.
Force all internet-bound traffic from spoke VNets to be inspected by a central Azure Firewall in the hub VNet.
Apply a Route Table with a User-Defined Route (UDR) to the spoke subnets. The UDR is a default route (0.0.0.0/0) pointing to the firewall's private IP.
Why: A UDR overrides Azure's default system route to the internet, allowing you to control and centralize egress traffic flow for security inspection.
Provide secure RDP/SSH access to VMs that have no public IP addresses, without configuring a VPN.
Deploy Azure Bastion into a dedicated subnet (AzureBastionSubnet) in the VNet.
Why: Bastion provides a managed jump box service, allowing secure administrative access via the Azure portal over TLS, eliminating public IP exposure on VMs.
Ensure traffic between a VM and a PaaS service (e.g., Azure SQL) stays on the private network and the PaaS service is not publicly accessible.
Create a private endpoint for the PaaS service in the VM's VNet and disable public network access on the PaaS service.
Why: A private endpoint gives the PaaS service a private IP within your VNet, while disabling public access ensures it's only reachable via that private IP.
Route global users to the nearest regional application endpoint to ensure the lowest possible latency.
Use Azure Traffic Manager with the "Performance" routing method.
Why: The Performance routing method uses DNS to direct clients to the endpoint with the lowest network latency from their location.
Send a notification (email, SMS, webhook) when a resource metric (e.g., VM CPU percentage) exceeds a threshold for a set duration.
Create a Metric Alert rule in Azure Monitor and link it to an Action Group that defines the notification action.
Why: This is the standard pattern. The alert rule defines the condition (what/when), and the action group defines the resulting notification (who/how).
Determine if traffic between two VMs is being blocked by a specific Network Security Group (NSG) rule.
Use the IP Flow Verify tool in Azure Network Watcher.
Why: IP Flow Verify simulates a packet flow and explicitly reports which NSG and rule is allowing or denying the traffic, making it the definitive tool for troubleshooting NSG conflicts.
Configure scheduled, policy-based backups for Azure VMs with application consistency and long-term retention.
Create a Recovery Services vault, define a backup policy (schedule, retention), and enable backup for the target VMs.
Why: The Recovery Services vault is the central management entity for Azure Backup. It stores backup data securely and manages all backup and restore operations.
Create a centralized dashboard to monitor performance (CPU, Memory, Disk, Network) of VMs across multiple subscriptions.
Deploy a central Log Analytics workspace and enable VM Insights for all target VMs, pointing them to the workspace.
Why: VM Insights collects and aggregates performance data, providing pre-built workbooks and a consolidated "at-scale" performance view across subscriptions.
Proactively identify underutilized Azure resources and opportunities for cost savings (e.g., VM right-sizing).
Regularly review the Cost recommendations in Azure Advisor.
Why: Azure Advisor automatically analyzes resource usage and provides actionable, personalized recommendations for cost savings without requiring additional configuration.
Replicate Azure VMs from a primary region to a secondary region to provide disaster recovery capability.
Use Azure Site Recovery. Create a Recovery Services vault and enable replication for the VMs to the target region.
Why: ASR is the native Azure service for orchestrating VM replication, failover testing, and failover/failback between Azure regions.
Set different data retention periods for security logs vs. performance logs within a single Log Analytics workspace to optimize cost.
Set a workspace-level default retention and then configure a longer retention period at the individual table level (e.g., for the SecurityEvent table).
Why: Per-table retention allows you to meet long-term compliance needs for specific data while minimizing storage costs for less critical, high-volume data.