Last reviewed: May 2026
A scannable reference of architectural patterns the AZ-900 exam tests. Read top-to-bottom, or jump to a section.
Shift IT spending from large, upfront hardware purchases to a pay-as-you-go model.
Leverage the cloud consumption-based model.
Why: This converts Capital Expenditure (CapEx) into predictable Operational Expenditure (OpEx), eliminating the need for data center procurement and management.
Understand the division of security and management duties between the cloud provider and the customer.
The provider is responsible for the security *of* the cloud; the customer is responsible for security *in* the cloud. Customer always owns their data, identities, and endpoints.
Why: In IaaS, the customer manages the OS and up. In PaaS, the provider manages the OS, and the customer manages the application and data. In SaaS, the provider manages everything except data and access configuration.
Choose a deployment model based on control, tenancy, and location requirements.
Use Public (shared infra), Private (dedicated infra, on-prem or hosted), or Hybrid (mix of Public and Private).
Why: Hybrid is key for retaining on-prem systems for regulation/latency while using public cloud for scalability and modern services. Private offers max control.
Select the right cloud service model based on the level of management control desired.
IaaS (e.g., Azure VMs) for max control over the OS. PaaS (e.g., Azure App Service, Azure SQL) to focus on code, not infrastructure. SaaS (e.g., Microsoft 365) for ready-to-use software.
Why: The trade-off is control vs. convenience. As you move from IaaS to SaaS, the provider manages more of the stack, reducing customer operational burden.
Handle dynamic, unpredictable traffic spikes vs. planned, sustained growth.
Use Elasticity for automatic scaling (in/out) to match real-time demand. Use Scalability for planned capacity increase (out/up) to handle projected growth.
Why: Elasticity is automated and reactive, ideal for spiky workloads to optimize costs. Scalability is a broader concept of adding capacity, which can be manual or automated.
Protect against component failure within a region vs. a catastrophic regional outage.
Implement High Availability (HA) using Availability Zones to survive data center failures. Implement Disaster Recovery (DR) using cross-region replication (e.g., GRS) to survive a regional disaster.
Why: HA is about maintaining service with minimal disruption. DR is about recovering service after a major outage. HA is typically automated with fast failover; DR often involves a formal recovery process.
Deploy resources for a government entity requiring specific compliance and data residency.
Use a sovereign cloud like Azure Government.
Why: These are physically isolated instances of Azure, managed by screened personnel, and designed to meet stringent government compliance standards (e.g., FedRAMP, DoD).
Design a resilient application that can withstand a data center failure.
Deploy resources across multiple Availability Zones within a single Azure Region.
Why: Availability Zones are physically separate data centers with independent power, cooling, and networking. This provides high availability within a region without the latency of cross-region deployments.
Group related Azure resources for unified management, access control, and billing.
Place all resources for an application in a single Azure Resource Group.
Why: Resource groups are containers for metadata. Deleting a resource group deletes all resources within it, making it a critical lifecycle management boundary.
Select the appropriate compute service for a workload.
VMs (IaaS) for full control. App Service (PaaS) for web apps/APIs. Azure Functions for event-driven serverless code. AKS for container orchestration. ACI for simple container instances.
Why: The choice depends on the trade-off between control, management overhead, and architectural pattern (e.g., monolith, microservices, event-driven).
Run a complex, containerized microservices application requiring auto-scaling, service discovery, and rolling updates.
Use Azure Kubernetes Service (AKS).
Why: AKS is the managed Kubernetes offering for full-scale container orchestration. Use this over ACI when you need cluster management and complex service interactions.
Run a single, simple container for a short-lived task (e.g., a batch job) without infrastructure management.
Use Azure Container Instances (ACI).
Why: ACI is the fastest and simplest way to run a container in Azure. It is serverless and billed per-second, ideal for tasks without orchestration needs.
Establish a dedicated, private, high-bandwidth connection from an on-premises data center to Azure.
Use Azure ExpressRoute.
Why: ExpressRoute does NOT traverse the public internet, offering greater reliability, security, and lower latency than a VPN Gateway, which tunnels over the internet.
Distribute traffic to backend VMs based on network-level vs. application-level rules.
Use Azure Load Balancer for Layer 4 (TCP/UDP) distribution. Use Azure Application Gateway for Layer 7 (HTTP/HTTPS) features like SSL offloading and URL-based routing.
Why: Choose Application Gateway when you need to make routing decisions based on HTTP headers, paths, or hostnames. Load Balancer is simpler and faster for non-HTTP traffic.
Route global web traffic to the optimal backend, provide CDN caching, and protect with a WAF.
Use Azure Front Door.
Why: Front Door is a global entry point that operates at Layer 7 and combines global load balancing, CDN, WAF, and DDoS protection into a single service.
Store massive amounts of unstructured data like images, videos, backups, and log files.
Use Azure Blob Storage.
Why: Blob storage is highly scalable and cost-effective for object data. It is distinct from Azure Files (for SMB file shares) and Azure Disk Storage (for VM disks).
Minimize storage costs for data based on its access frequency.
Use Blob Storage access tiers: Hot (frequent access), Cool/Cold (infrequent access), and Archive (rare access, long-term retention).
Why: Archive tier has the lowest storage cost but the highest access cost and latency (hours to rehydrate). Use lifecycle management policies to automate tiering.
Choose a data replication strategy to protect against hardware, data center, or regional failure.
LRS (single data center), ZRS (across AZs in one region), GRS (to a secondary region), GZRS (ZRS in primary + LRS in secondary).
Why: ZRS protects from a data center failure. GRS/GZRS protects from a regional disaster. The trade-off is higher cost for greater resiliency.
Allow a VM in a VNet to access a PaaS service (like Azure SQL or Storage) without traffic leaving the Microsoft network.
Create a Private Endpoint for the PaaS service within the VM's VNet.
Why: A Private Endpoint gives the PaaS service a private IP address from your VNet, ensuring all traffic flows over the private Microsoft backbone, not the public internet.
Migrate an on-premises Windows file server to a managed cloud service accessible via SMB protocol.
Use Azure Files.
Why: Azure Files provides fully managed file shares that can be mounted by cloud or on-premises VMs, acting as a direct replacement for traditional file servers.
Apply governance (policies, RBAC) and manage access across numerous Azure subscriptions.
Organize subscriptions into a Management Group hierarchy.
Why: Management groups are a scope above subscriptions. Policies and role assignments applied at a management group level are inherited by all subscriptions within it.
Enforce organizational standards, such as restricting deployments to specific regions or requiring tags on all resources.
Use Azure Policy.
Why: Policy enforces rules on resource configurations. This is for governance, whereas RBAC controls user permissions (actions).
Distinguish between controlling user actions and controlling resource properties.
Use Role-Based Access Control (RBAC) to define what actions a user can perform (e.g., "Contributor" can create VMs). Use Azure Policy to define what configurations are allowed (e.g., "VMs can only be of D-series size").
Why: RBAC is about "who can do what". Policy is about "what is allowed". They work together for comprehensive governance.
Protect a critical production resource from accidental deletion, even by administrators.
Apply a `CanNotDelete` Resource Lock to the resource or its resource group.
Why: Resource locks override RBAC permissions. An Owner cannot delete a locked resource until the lock is explicitly removed. A `ReadOnly` lock prevents any modifications.
Logically organize resources for cost tracking, automation, or ownership identification.
Apply Tags (key-value pairs) to resources.
Why: Tags are metadata used for filtering and grouping resources across resource groups, enabling powerful cost analysis and management.
A tag applied to a resource group is not showing up on the resources within it.
Tags are not automatically inherited from resource groups. Each resource must be tagged explicitly.
Why: To enforce tag inheritance, use an Azure Policy with a "Modify" or "DeployIfNotExists" effect to append tags from the parent resource group.
Estimate future Azure costs vs. calculating savings from an on-prem migration.
Use the Pricing Calculator to estimate the cost of specific Azure services. Use the Total Cost of Ownership (TCO) Calculator to compare on-prem costs vs. Azure costs.
Why: The Pricing Calculator is for greenfield deployments or adding new services. The TCO Calculator is for building a business case for migration.
Track current Azure spending, set spending alerts, and find savings opportunities.
Use Azure Cost Management. Create Budgets to trigger alerts when spend thresholds are met.
Why: Budgets provide proactive notification of spending, helping to prevent cost overruns. Cost Management analysis helps identify spending anomalies and trends.
Reduce costs for predictable, continuously running workloads like VMs or databases.
Purchase Azure Reserved Instances or Savings Plans for a 1- or 3-year term.
Why: Reservations offer significant discounts (up to 72%) over pay-as-you-go pricing in exchange for a long-term commitment. Ideal for steady-state workloads.
Deploy Azure infrastructure repeatably, consistently, and under version control.
Use declarative Infrastructure as Code (IaC) with ARM Templates (JSON) or Bicep.
Why: Bicep is a simpler, more concise domain-specific language (DSL) that transpiles to ARM JSON, providing better authoring experience and readability.
Manage and govern servers running on-premises or in other clouds using Azure tools.
Onboard the non-Azure servers to Azure Arc.
Why: Azure Arc projects external resources into Azure Resource Manager, allowing you to use Azure Policy, RBAC, and monitoring for hybrid and multi-cloud assets from a single control plane.
Provide a single, cloud-based identity and access management solution for all applications.
Use Microsoft Entra ID (formerly Azure AD).
Why: Entra ID is the identity control plane, providing Single Sign-On (SSO), Multi-Factor Authentication (MFA), and Conditional Access for cloud and on-prem apps.
Require MFA for users signing in from an untrusted network but not from the corporate office.
Configure a Microsoft Entra Conditional Access policy.
Why: Conditional Access acts as an "if-then" policy engine. If a user/location/device condition is met, then an access control (like requiring MFA) is enforced.
Allow an Azure resource (like a VM or App Service) to authenticate to another Azure service (like Key Vault) without storing secrets in code.
Assign a Managed Identity to the resource and grant it RBAC permissions on the target service.
Why: Azure manages the credential lifecycle automatically, eliminating the risk of leaked secrets from configuration files or code.
Securely store and manage application secrets, keys, and certificates.
Use Azure Key Vault.
Why: Key Vault provides a centralized, hardware-secured, and audited repository for secrets, preventing them from being hard-coded in applications.
Continuously assess the security posture of cloud workloads, get a Secure Score, and receive threat protection.
Use Microsoft Defender for Cloud.
Why: Defender for Cloud provides Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) across Azure, hybrid, and multi-cloud environments.
Filter network traffic at the subnet/NIC level vs. centrally for the entire VNet.
Use Network Security Groups (NSGs) for basic Layer 3/4 stateful packet filtering. Use Azure Firewall for a centralized, fully stateful firewall-as-a-service with Layer 7 filtering and threat intelligence.
Why: NSGs are simple and distributed. Azure Firewall provides advanced capabilities and centralized policy management, often used in a hub-spoke topology.
Reduce the attack surface of VMs by keeping management ports (RDP/SSH) closed by default.
Enable Just-In-Time (JIT) VM access in Microsoft Defender for Cloud.
Why: JIT grants temporary access to management ports on-demand for a limited time, automatically closing them afterward. This is more secure than leaving ports perpetually open.
Monitor the health of Azure infrastructure vs. the performance of application code.
Use Azure Monitor for platform metrics and logs. Use Application Insights (a feature of Azure Monitor) for Application Performance Management (APM).
Why: Azure Monitor collects infrastructure data (CPU, memory). Application Insights provides deep code-level diagnostics (response times, dependencies, exceptions).
Receive personalized alerts about Azure service outages, planned maintenance, and health advisories.
Use Azure Service Health.
Why: Service Health is personalized to your subscriptions, regions, and services, unlike the public Azure Status page. It is for Azure platform issues, not your own resource health.
Receive personalized, actionable recommendations to optimize Azure resources.
Review Azure Advisor recommendations.
Why: Advisor analyzes your configuration and usage telemetry and provides recommendations across five pillars: Reliability, Security, Performance, Cost, and Operational Excellence.
Establish a standardized, governed, and scalable foundation for all Azure workloads in an enterprise.
Implement an Azure Landing Zone architecture.
Why: Landing Zones provide a prescriptive framework from the Cloud Adoption Framework, including management group structure, networking, identity, and governance policies, to accelerate cloud adoption securely.