AZ-900 Cheat Sheet

Cloud computing delivers compute, storage, networking, databases, and software as metered services over the internet, so you rent capacity and release it when you're done instead of buying and maintaining a datacenter. On Microsoft Azure you provision a resource in minutes and pay only for what you use, with the provider maintaining the underlying power, cooling, hardware, and networking.

Azure is a public cloud where many customers (tenants) share the same physical infrastructure while staying logically isolated from one another. A tenant is a dedicated instance of a Microsoft Entra directory holding an organization's identities and resources, so isolation is logical, not a separate physical environment per customer.

Trap Assuming a public-cloud tenant gets its own dedicated physical hardware: multi-tenancy isolates customers logically while they share the same hosts.

The shared responsibility model defines which security tasks belong to Microsoft and which to the customer, and the boundary shifts with the service type. The more managed the service (IaaS → PaaS → SaaS), the more responsibility moves to Microsoft. In IaaS you still own the OS, applications, and network controls, while in SaaS Microsoft handles all but your data, identities, and access.

Across IaaS, PaaS, and SaaS, Microsoft is always responsible for the physical datacenters, the physical network, and the physical hosts (plus the hypervisor). The customer never secures the hardware in a public cloud, no matter the service model.

Trap Assuming the customer secures the physical hosts or datacenter in IaaS, when Microsoft owns the physical layer at every service model.

Regardless of service model, even SaaS, the customer always retains responsibility for their data, accounts/identities, client endpoints, and access management. These four never transfer to Microsoft, which makes them the single most common shared-responsibility trap on the exam.

Trap Assuming a fully managed SaaS service makes Microsoft responsible for your data and user identities: those stay with the customer at every service tier.

A public cloud is built, controlled, and maintained by a third-party provider (Microsoft) and open to anyone who purchases its services, with no capital expenditure to scale up and pay-only-for-what-you-use billing. The tradeoff is that you don't have complete control over the resources and security the provider operates.

Trap Picking public cloud when the scenario demands complete control and data that is not collocated with other tenants, which points to private cloud.

A private cloud is used exclusively by a single organization and gives the most control over resources and security, with your data not collocated with other tenants'. You must purchase and maintain the hardware yourself, so it carries greater cost and fewer of the public cloud's elasticity benefits.

Trap Assuming a private cloud removes up-front hardware cost like public cloud, when you still buy and maintain the hardware yourself.

A hybrid cloud links a public cloud with a private cloud or on-premises datacenter in one interconnected environment, letting a private cloud surge into public capacity for temporary demand. It gives the most flexibility: you choose which workloads run where to meet security, compliance, or legal requirements, e.g. keeping regulated data private while bursting elsewhere.

Trap Choosing multicloud for a scenario that keeps some workloads private or on-premises while using public cloud, which is hybrid, not multiple public providers.

Multicloud means using two or more public cloud providers at once (often to use the best feature from each or while migrating between them) so you manage resources and security across both. Azure Arc can help manage resources spanning public, private, hybrid, and multicloud environments.

Trap Labeling a public-plus-on-premises setup as multicloud, when multicloud means two or more public cloud providers and that mix is hybrid.

Map the scenario to its model: no up-front cost plus quick scale-up points to public cloud; complete control with data not collocated and strict requirements points to private cloud; keeping some workloads on-premises or private while using public cloud points to hybrid. Multiple public providers at once is multicloud.

Trap Confusing hybrid with multicloud, where hybrid mixes public with private or on-premises and multicloud uses two or more public providers.

Capital expenditure (CapEx) is up-front spending on physical infrastructure (servers, network hardware, datacenter space) that is depreciated over years. It is the traditional on-premises model and forces capacity planning that risks over- or under-provisioning.

Trap Classifying pay-as-you-go cloud spending as CapEx, when CapEx is up-front depreciated hardware and consumption billing is OpEx.

Operational expenditure (OpEx) is ongoing spending on services as you consume them, with no physical asset to depreciate. Because you pay for cloud services as you use them, cloud computing is classified as an operating expense, not a capital one.

Trap Treating an up-front depreciated hardware purchase as OpEx, when that is CapEx and only consumed-as-you-go service spending is OpEx.

Azure runs on a consumption-based, pay-as-you-go model: you pay only for the IT resources you use and release them, and stop paying, when you're done. This removes up-front hardware cost and the need to buy capacity that may sit idle, letting you scale out at peak and back in when demand drops.

Azure Reservations commit to a one- or three-year term in exchange for a discount of up to 72% over pay-as-you-go, applied automatically to matching resources. They are the right pick for consistent, always-on base usage, not for bursty or short-lived workloads where consumption pricing fits better.

Trap Choosing reservations for bursty or short-lived workloads, when a one- or three-year commitment fits steady always-on usage and consumption pricing fits intermittent demand.

Azure Spot Virtual Machines run on Azure's unused capacity at a significant discount, but there is no SLA and Azure evicts them with only 30 seconds' notice whenever it needs the capacity back. They fit interruptible, fault-tolerant work (batch jobs, dev/test, large compute) not critical always-on services.

Trap Running a production always-on service on Spot to save money: a 30-second eviction with no SLA takes the node down whenever Azure reclaims capacity.

Serverless computing has the platform provision, scale, and maintain the servers while you supply only code: you never deploy or patch the underlying infrastructure. Azure Functions is Azure's serverless compute service, letting you run code without managing the VMs it runs on.

Serverless code runs in response to triggers (HTTP, timer, queue, blob change), scales automatically with the number of incoming events, and on the consumption plan bills only on executions, execution time, and memory used. When nothing runs you pay nothing for compute, making it ideal for spiky or intermittent workloads.

Serverless suits short, stateless, intermittent tasks: on the Azure Functions consumption plan a function execution times out after a configurable maximum and idle instances incur cold starts. Long-running or always-on, latency-sensitive services are better on dedicated or premium (always-warm) compute that doesn't time out or cold-start.

Trap Reaching for the serverless consumption plan for a long-running, latency-sensitive service, when execution timeouts and cold starts make dedicated or premium compute the fit.

Azure Reservations provide a billing discount of up to 72% over pay-as-you-go for a one- or three-year commitment, applied automatically to matching resources without changing their runtime state. A reservation covers only the compute capacity (additional software, Windows licensing, networking, and storage are billed separately), and the discount is applied on an hourly basis: any hour without a matching resource forfeits that hour's benefit.

Trap Assuming a reservation covers Windows licensing, networking, and storage too, when it discounts only the compute capacity and those are billed separately.

High availability (HA) keeps an application running and reachable with minimal downtime even when individual components fail, and the cloud achieves it with redundant infrastructure that removes single points of failure. On AZ-900 the fingerprint is "stay online," "survive an outage," or "no single point of failure." HA is about avoiding downtime, not about handling more load.

Trap Confusing high availability with scalability: both use multiple instances, but HA is about staying up, scalability is about having enough capacity.

Availability zones are separated groups of datacenters within a single region, each with independent power, cooling, and networking, so if one zone fails the others keep serving, typically within ~100 km of each other for low-latency replication. A resource is zone-resilient only once it spans two or more zones, and many Azure SLAs require a multi-zone deployment to reach their highest uptime tier. Use them for in-region HA; they do not protect against a full-region outage.

Trap Assuming a single availability zone is redundant: one zone is one logical group of datacenters, and zonal (single-zone) deployment carries no cross-zone protection.

Scalability is the ability to add or remove resources so capacity matches workload demand. It is distinct from high availability: scalability is about having enough capacity, HA is about staying online. A stem about handling more users or growing load points to scalability.

Trap Picking high availability when the stem is about growing load, since HA targets staying online through failures while scalability targets having enough capacity for demand.

Scaling up (vertical) adds power to a single instance (moving a VM to a SKU with more CPU and RAM) and is capped by the largest hardware available, sometimes needing a restart. Scaling out (horizontal) adds more identical instances behind a load balancer and is the cloud-preferred path because it has no fixed ceiling. Shorthand: "bigger machine" = up, "more machines" = out.

Trap Confusing scaling up with scaling out, since up resizes a single instance vertically while out adds more identical instances horizontally.

Elasticity is scaling that happens automatically as load rises and falls, with no manual intervention, delivered through autoscale on services like Virtual Machine Scale Sets and the Web Apps feature of Azure App Service. Autoscale is horizontal only: it adds and removes instances, never resizes one, and triggers on metrics (CPU, queue length) or a schedule. The signal is "automatically handle spikes" or "scale in when traffic drops."

Trap Treating autoscale as vertical scaling: it scales out and in by instance count, it does not give a single machine more CPU or memory.

The consumption-based (pay-as-you-go) model charges you only for the resources you actually consume, with no upfront capital outlay, so elastic autoscaling lets you avoid provisioning (and paying) for a rare worst-case peak. This is the financial benefit that pairs with elasticity: capacity follows demand, and so does the bill.

Trap Treating consumption pricing as a capital expense, since pay-as-you-go is an operational expense (OpEx) with no upfront CapEx outlay.

Reliability is a system's ability to be resilient (withstand faults), recoverable (restore within agreed targets after a disruption), and available, one of the five pillars of the Azure Well-Architected Framework. It is broader than HA: reliability also covers recovering through backup and regional failover after a failure, not only staying up. The five pillars are Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.

Trap Equating reliability with high availability alone, when reliability also covers recovering through backup and failover after a disruption, not just avoiding downtime.

Performance predictability keeps the user experience consistent as load changes, achieved with autoscale (add capacity on demand) and load balancing (spread traffic so no single instance is overwhelmed). The signal is "consistent response times during a traffic surge." It is the performance half of predictability, distinct from cost predictability.

Trap Answering cost predictability when the stem is about consistent response times under load, which is the performance half, not the spend-forecasting half.

Cost predictability is forecasting and tracking spend accurately, using the Pricing Calculator (a free, unauthenticated tool to estimate a planned deployment before anything is provisioned) and Microsoft Cost Management (track and analyze actual spend after deployment, with budgets and alerts). On-premises-vs-Azure TCO comparison now runs through the Azure Migrate business case feature. Signal: "estimate monthly cost before deploying" → Pricing Calculator; "forecast and track the bill" → Cost Management.

Trap Reaching for the Total Cost of Ownership (TCO) Calculator: Microsoft has retired the standalone TCO Calculator, and on-prem-vs-Azure cost analysis now lives in Azure Migrate.

AZ-900 tests predictability as two distinct halves: performance predictability (consistent experience under load) and cost predictability (forecastable, trackable spend). A single "predictability" answer can be wrong if the stem is actually about the other half: read whether it is about performance or spend before answering.

Defense in depth layers multiple overlapping protections (physical, identity, network, application, data) so breaching one layer does not compromise the whole system. As a cloud benefit it means you inherit Microsoft's continuously updated security investment across the lower layers rather than building every layer yourself.

Under the shared responsibility model Microsoft always secures the physical hosts, network, and datacenters, while you always retain responsibility for your data, identities, accounts, and access management, regardless of whether the workload is IaaS, PaaS, or SaaS. Responsibility for the OS, network controls, and applications shifts toward Microsoft as you move IaaS → PaaS → SaaS. Cloud security is a benefit because Microsoft owns the layers you cannot.

Trap Assuming the cloud provider is responsible for securing your data and identities, when those always stay your responsibility across IaaS, PaaS, and SaaS.

Microsoft Defender for Cloud continuously assesses your posture and rolls it into a Secure Score that rises as you remediate its recommendations, and adds threat protection across Azure, hybrid, and multicloud resources. Its free Foundational CSPM tier covers Secure Score and recommendations; paid Defender plans add workload threat protection (CWPP). It is the centralized tooling that operationalizes the cloud's security benefit (formerly Azure Security Center).

Trap Confusing Defender for Cloud with Microsoft Sentinel, when Defender assesses posture and Secure Score while Sentinel is the cloud-native SIEM for security event analytics.

Governance is applying organizational standards and staying compliant across many resources without manual, per-resource effort. The AZ-900 signal is "ensure every team follows company standards" or "deploy a compliant environment repeatedly": about standardizing and enforcing rules, not about protecting against attackers (that is security).

Trap Picking security when the stem is about enforcing company standards, since governance standardizes and enforces rules while security protects against attackers.

Azure Policy enforces organizational standards and assesses compliance at scale (for example "allow only approved regions" or "require a tag") evaluating resources against business rules and applying effects that audit (flag) or deny (block) non-compliant ones. It is the governance enforcement service the exam pairs with compliance and consistency scenarios. Group related policies into an initiative to assign them as one unit.

Trap Picking Azure RBAC for compliance: RBAC controls who can perform actions, while Azure Policy controls whether the resulting resource state is allowed.

ARM templates (and Bicep) define infrastructure as code so a compliant configuration deploys identically every time, delivering governance by making standard setups reproducible. Azure Blueprints packaged policies, role assignments, and templates into a reusable environment baseline, but it is a Preview service deprecating July 11, 2026. Microsoft directs customers to Template Specs and Deployment Stacks, and Azure Policy is the current AZ-900 governance enforcement tool.

Trap Reaching for Azure Blueprints as the current governance tool, when it is a deprecating Preview service and Azure Policy is the present-day enforcement service.

Security is about protecting resources (defense in depth, Defender for Cloud); governance is about standardizing and enforcing rules (Azure Policy). "Block deployments outside approved regions" is governance, not security: a common AZ-900 discriminator that hinges on whether the stem is about threat protection or about consistency/compliance.

Manageability has two halves the exam distinguishes: management of the cloud (the platform manages itself for you: autoscale, automatic provisioning, self-healing, monitoring) and management in the cloud (the tools you use to configure and operate resources). Read which side a stem is testing before choosing.

Management of the cloud is the platform doing work automatically on your behalf: autoscale, automatic resource provisioning, self-healing (automatic recovery of unhealthy resources), and continuous monitoring of resource health. You get the benefit without performing the work: it is the automated, platform-side half of manageability.

Trap Confusing management of the cloud with management in the cloud, since 'of' is the platform acting automatically for you while 'in' is the tools you operate yourself.

Management in the cloud is the toolset you use to operate resources: the Azure portal (graphical web UI) for ad-hoc work, Azure CLI and Azure PowerShell for command-line scripting and automation, the Azure mobile app, and ARM/Bicep templates for repeatable infrastructure as code. Match the tool to the job: portal for one-off changes, CLI/PowerShell for automation, templates for reproducible deployments.

Trap Treating autoscale or self-healing as management in the cloud, when those are management of the cloud and 'in' is the tooling you operate yourself.

Cost predictability is forecasting and tracking spend reliably; it is distinct from the cost savings benefit (the CapEx-to-OpEx shift and pay-as-you-go pricing). Match "forecast the bill" or "track where spend goes" to the cost tools, not to a generic "the cloud is cheaper" claim.

Trap Choosing cost savings when the stem is about forecasting and tracking spend, since that is cost predictability rather than the CapEx-to-OpEx savings benefit.

Because both often use multiple instances, AZ-900 offers high availability and scalability as competing answers. Anchor on the goal: staying up through a failure = availability; having enough capacity for demand = scalability. Good designs combine them, but the exam tests them as separate benefits.

Virtual Machine Scale Sets create all instances from the same base OS image and configuration, eliminating configuration drift and letting you manage hundreds of identical VMs without per-machine setup. They are also the foundation for autoscale, illustrating the manageability benefit of treating many machines as one managed pool.

Azure Resource Manager orchestrates a template by deploying resources that have no dependencies in parallel while still creating interdependent resources in the correct order. This parallel orchestration finishes multi-resource deployments faster than running serial, imperative commands, and you trigger it with a single command.

ARM templates use declarative syntax: you state the desired end state of your resources and Azure works out how to reach it, instead of writing step-by-step commands. Because the template is code (a JSON file), teams store it in source control to version, review, and roll back infrastructure changes like application code.

Trap Calling ARM templates imperative, when declarative syntax states the desired end state rather than the step-by-step commands to reach it.

ARM templates are idempotent: deploying the same template repeatedly yields the same resource types in the same state. If a resource with the specified properties already exists, no change is made. This gives repeatable, consistent results, so identical infrastructure can be reproduced across dev, test, and production from one template.

ARM templates plug into continuous integration and continuous deployment tools such as Azure Pipelines and GitHub Actions, automating release pipelines for fast, reliable infrastructure updates. This supports the agility benefit: responding quickly to changing requirements by shipping infrastructure changes through the same automated pipeline as code.

Azure Backup backs up Azure VMs, files, Azure Files, databases, and on-premises workloads into a Recovery Services vault, guarding against accidental deletion, corruption, and ransomware. It runs at cloud scale with no on-premises backup infrastructure to maintain, automatically managing backup storage on a pay-as-you-use model. It is the recovery side of reliability: restoring data, distinct from availability's goal of avoiding downtime.

Trap Confusing Azure Backup with Azure Site Recovery, when Backup restores data from a vault and Site Recovery replicates and fails over workloads to keep them running.

Geo-redundant storage (GRS) first replicates data within the primary region, then copies it asynchronously to a secondary paired region hundreds of miles away, protecting against a full regional outage or disaster. GRS is the default and recommended option for a Recovery Services vault. Choose it when data must survive the loss of an entire region; contrast with LRS (one datacenter) and ZRS (across zones in one region).

Trap Relying on locally redundant storage (LRS) for disaster recovery. LRS keeps all copies in a single datacenter and won't survive a regional outage.

Microsoft Cost Management is a native suite of FinOps tools to analyze, monitor, and optimize Azure spend, available to anyone with billing, subscription, resource-group, or management-group access at no additional charge to use the tooling itself. Its Cost analysis breaks spend down by service, location, subscription, resource group, or tag so you can see exactly where costs originated, and it supports budgets and cost alerts.

Trap Reaching for the Pricing Calculator to track actual spend, when that tool only estimates planned cost before deployment and Cost Management analyzes spend after deployment.

Cloud offerings fall into three service models (Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)) distinguished by how much of the stack the provider manages versus you. IaaS is essentially renting datacenter hardware, PaaS adds a managed runtime platform on top, and SaaS is a finished application you simply use.

Across IaaS → PaaS → SaaS you trade control for convenience: IaaS is the most flexible with maximum control and the largest operational responsibility, while SaaS is the least flexible but easiest to stand up and needs the least technical expertise. PaaS sits in the middle, splitting duties roughly evenly between you and the provider.

Trap Assuming SaaS gives the most control because the provider manages the most, when in fact SaaS gives the customer the least control and IaaS the most.

Under IaaS the provider maintains only the physical hardware, internet connectivity, and physical security; you own everything else: operating-system install/config/patching, network configuration, and database/storage setup. You're essentially renting cloud hardware and what you do on it is up to you, which is why IaaS carries the heaviest operational load.

Trap Assuming the provider patches the guest operating system under IaaS, when OS install, configuration, and patching stay with the customer.

Under PaaS the provider maintains the physical infrastructure plus the operating systems, middleware, development tools, and managed runtimes, so you never handle OS or database licensing and patching. You focus only on your application code, data, and access controls: a complete development platform without maintaining the underlying infrastructure.

Trap Treating OS and runtime patching as the customer's job under PaaS, when the provider owns the operating system, middleware, and runtime there.

Under SaaS the provider manages almost the entire stack (infrastructure, platform, and the application itself, including updates and patching) giving customers the lowest operational overhead. You manage only your data, identity and access settings, and which devices may connect; you're essentially using a fully developed application.

Trap Assuming the customer has nothing to manage under SaaS, when the customer still owns their data, identities and access, and the devices allowed to connect.

Azure Virtual Machines and Azure Virtual Network are IaaS: you pick the VM image and size, then patch the guest OS and deploy your app yourself. This is the model for lift-and-shift migrations and for software with specific OS or driver dependencies that need operating-system-level control.

Azure App Service (web apps and APIs), Azure SQL Database (managed relational database), and Azure Functions (serverless code) are PaaS: you supply code or schema and Microsoft handles the OS, runtime, patching, and scaling. App Service runs web apps "without worrying about managing the underlying infrastructure," and Functions runs your code without you deploying or maintaining servers.

Trap Classifying Azure App Service or Functions as IaaS because they run your code, when Microsoft owns the OS, runtime, and scaling, making them PaaS.

Microsoft 365 (email and productivity) and Dynamics 365 (CRM/ERP) are SaaS: fully developed applications you sign in to and consume over the internet, with no infrastructure or platform to maintain. Email, messaging, and finance/productivity apps are the classic SaaS scenarios.

Pick IaaS when the scenario needs operating-system control, a lift-and-shift migration of existing servers with minimal change, or rapid spin-up/tear-down of dev-and-test environments while keeping full control. It's also the fit for software with specific OS or driver dependencies that a managed platform can't accommodate.

Trap Reaching for PaaS for a lift-and-shift migration of existing servers, when minimal-change migration and OS-level control point to IaaS.

Pick PaaS when developers want to build and deploy custom applications without patching, scaling, or otherwise managing the underlying servers: the provider supplies the development framework, and cloud features like scalability and high availability come built in. Analytics and business-intelligence tooling delivered as a service is the other classic PaaS use case.

Trap Picking IaaS when developers want to deploy custom code without managing servers, when avoiding server management points to PaaS.

Pick SaaS when a finished, subscription-based product (email, CRM, office productivity) already meets the need and you want the fastest time to value with the least technical effort. There's nothing to build or maintain; you just sign in and use it.

Trap Reaching for PaaS to build an application when a finished off-the-shelf product like email or CRM already meets the need, which is the SaaS case.

The shared responsibility model divides duties between customer and provider, and the dividing line shifts with the service type: IaaS places the most on you, SaaS the most on the provider, and PaaS distributes them roughly evenly. Identifying the service type in a question is what tells you who owns a given task.

Regardless of IaaS, PaaS, or SaaS, the customer always owns the information and data stored in the cloud, the accounts and identities, and the devices allowed to connect. The provider always owns the physical datacenter, physical network, and physical hosts; only the layers in between shift by service type.

Trap Assuming the provider owns your data and identities under SaaS because it runs the application, when data, identities, and devices stay the customer's at every service type.

OS patching ownership depends on the service type: in IaaS the customer patches the guest operating system, while in PaaS Microsoft handles OS (and database) patching and licensing. The identical task therefore has a different owner depending on which service type the question names.

Trap Assuming the provider patches the guest OS in IaaS the same way it does in PaaS, when OS patching is the customer's job under IaaS.

Map the action in the question stem to the service type: "manage/control the OS" points to IaaS, "just deploy code" or "no servers to manage" points to PaaS, and "use ready-made software" points to SaaS. The verb describing how much the team wants to manage is the fastest tell.

When a scenario explicitly says the team does NOT want to manage servers, the OS, or patching, IaaS is the tempting wrong answer because it's the most familiar model, but the correct choice is PaaS (deploy your own code) or SaaS (use off-the-shelf software). IaaS always keeps OS management with the customer.

Trap Choosing IaaS when the scenario says the team does not want to manage servers or the OS, when avoiding that management rules IaaS out in favor of PaaS or SaaS.

Azure SQL Database is a fully managed relational database-as-a-service in the PaaS category: Microsoft owns the host, patching, upgrades, and built-in high availability. That's distinct from running SQL Server yourself on an IaaS VM (SQL Server on Azure VMs), where you keep OS-level access and manage updates and HA.

Trap Treating Azure SQL Database as IaaS because it's a database: it's a managed PaaS service; only SQL Server installed on a VM is IaaS.

Azure's physical infrastructure nests as geography > region > availability zone > datacenter: a geography holds regions, a region holds availability zones, and a zone is one or more datacenters. You never touch a datacenter directly: you deploy into a region, and Azure groups the underlying datacenters into regions and zones for you.

Trap Inverting the nesting order so a region is treated as containing geographies rather than the geography containing regions.

A region is a geographical area holding one or more datacenters that are nearby and networked together over a low-latency network, and it's the unit you choose when you deploy most resources. That choice drives latency, which services and VM sizes are available, price, and where data lives, though a few global services (Microsoft Entra ID, Traffic Manager, Azure DNS) need no region.

Trap Confusing a region with an availability zone as the thing you select at deployment, when the region is the unit you pick and zones sit inside it.

A geography is a discrete market, typically a country, that contains two or more regions and exists to keep data inside a legal jurisdiction. Paired regions keep data within the same geography for residency and compliance, so a requirement like "data must stay within Germany" is a geography/region decision, not a zone one.

Trap Treating a data-residency requirement as an availability-zone choice when it is a geography/region decision.

A datacenter is the physical facility of server racks with dedicated power, cooling, and networking that Microsoft owns and operates: the bottom layer where resources actually run. You never deploy to a datacenter directly; Azure groups datacenters into regions and availability zones, and those are what you target.

A zone-enabled region contains a minimum of three separate availability zones, each a physically separate location with independent power, cooling, and networking connected by high-speed private fiber. The three-zone floor exists so a region can survive a full zone outage and still keep a quorum running.

Availability zones protect against the failure of a single datacenter or zone: replicate a workload across zones in the same region and it keeps running if one zone goes down. A requirement like "survive a datacenter failure" points to availability zones (staying inside one region) not to region pairs, which address losing the whole region.

Trap Reaching for a region pair when the requirement is in-region datacenter resilience: that over-provisions for a different (whole-region) failure.

Zonal services are pinned to a single availability zone you select (for example a Virtual Machine, managed disk, or public IP in zone 2), so you own spreading copies across zones for resilience. Zone-redundant services replicate across the region's zones automatically (for example zone-redundant storage or Azure SQL Database), and the platform handles the failover.

Trap Assuming a single zonal resource is zone-resilient: a lone zonal deployment dies with its zone unless you place instances in multiple zones yourself.

Availability zones exist only in zone-enabled regions, so zone-redundant deployment isn't possible everywhere. Before designing for in-region HA, confirm the region supports zones (or choose one that does); a region without zones falls back to region pairs and geo-redundant storage for resilience.

Trap Assuming every Azure region offers availability zones, when zones exist only in zone-enabled regions.

A region pair links two regions within the same geography at least 300 miles (~480 km) apart, so one natural disaster, outage, or civil disruption is unlikely to hit both. Region pairs are the basis for cross-region disaster recovery: examples are West US/East US and Southeast Asia/East Asia.

Trap Assuming a region's pair sits in a different geography, when both regions of a pair stay within the same geography.

Azure rolls planned platform updates to only one region of a pair at a time, so an update can't take down both halves at once. During a broad outage Azure also prioritizes restoring at least one region of every pair, but note that not all services auto-replicate or auto-fail-over across the pair, so the customer often must configure replication.

Trap Assuming every service automatically replicates and fails over across a region pair: many require you to configure cross-region replication yourself.

Availability zones give high availability against a single datacenter or zone failure while staying inside one region; region pairs give disaster recovery against losing an entire region. Match the failure scope to the answer: in-region resilience is zones, whole-region loss is region pairs.

Trap Picking region pairs for an in-region high-availability requirement, or zones for whole-region disaster recovery, matching the failure scope to the wrong construct.

Sovereign regions are instances of Azure physically and logically isolated from the main public cloud for strict government or national data-residency rules. The named clouds are Azure Government (US Gov / US DoD regions, run by screened US personnel) and Azure operated by 21Vianet (China regions). Reach for these only when data legally cannot touch the public cloud.

Trap Reaching for a sovereign cloud for ordinary data-residency needs, when a standard geography/region already keeps data in-country and sovereign clouds are only for strict government or legal isolation.

Azure Government serves US government agencies and partners through network-isolated regions (US Gov Virginia, US Gov Arizona, US DoD Central) operated by screened US staff with extra compliance certifications. Azure operated by 21Vianet runs China regions via a Microsoft–21Vianet partnership where Microsoft doesn't directly run the datacenters, satisfying Chinese law. Pick these when data must never leave the jurisdiction.

A resource group is a logical container for related resources, and every resource belongs to exactly one resource group at a time. You can move a resource to another group, but it can never live in two; resource groups also can't be nested or renamed after creation, so choose a naming convention up front.

Trap Assuming resource groups can be nested inside one another, when a resource group cannot contain another resource group.

Actions on a resource group cascade to everything inside it, so deleting the group deletes all its resources at once: handy for tearing down a temporary or per-project environment cleanly. The corollary is to group resources that share a lifecycle, since they get deployed, updated, and deleted together.

Trap Putting a long-lived shared resource in a throwaway resource group: deleting the group to clean up takes the shared resource down with it.

A resource group is a logical, not regional, boundary: it can hold resources located in several different regions. The group itself still has a location, but only to store its own metadata (control-plane data). Microsoft recommends matching it to the resources' region, though it doesn't constrain where the resources run.

Trap Treating a resource group's location as the region its resources run in: the group location only sets where the group's metadata is stored.

A subscription is a logical container for resource groups and the unit of billing, access control, and scale: Azure issues a separate invoice per subscription and applies access-management policies at the subscription level. Organizations spin up multiple subscriptions to separate environments (dev/test/prod), teams, or billing, since each gives its own cost report and access rules.

Trap Treating the resource group as the billing boundary, when invoices and quotas are scoped to the subscription.

A management group sits above subscriptions and lets you apply Azure Policy and RBAC role assignments to many subscriptions at once, with all subscriptions inheriting those conditions. Management groups can nest, all under a single root group per directory, so you can mirror an org structure for unified policy and access.

Trap Confusing a management group with a subscription as the level for cross-subscription governance, when the management group sits above subscriptions and they inherit its policies.

Azure has four management scope levels: resources live in a resource group, resource groups live in a subscription, and subscriptions roll up under management groups. This four-level hierarchy is the structure for governance: the level you assign a policy or role at determines how widely it applies.

Trap Misordering the scope levels, for example placing subscriptions inside resource groups instead of resource groups inside subscriptions.

An Azure Policy or RBAC role assignment made at a higher scope is automatically inherited by everything beneath it: a policy on a management group flows down to its subscriptions, resource groups, and resources. Inheritance only flows down: a sibling scope or a parent is never affected by an assignment made below it.

Trap Assuming an assignment made at a low scope bubbles up to affect a parent or sibling scope, when inheritance only flows downward.

Because assignments inherit downward, place organization-wide policy and roles at the management group or subscription scope so they cover everything below, and put narrow exceptions at the resource group or resource scope. A policy set high (e.g. allowed VM regions on a management group) can't be overridden by a resource owner below it, which is what makes it enforceable governance.

Trap Assuming a resource owner can override an organization-wide policy set at the management group scope, when a higher-scope assignment cannot be loosened from below.

Billing and access policies are scoped to the subscription, not the resource group; a resource group's costs simply roll up to its parent subscription. To truly separate spend (or quotas) between workloads, use different subscriptions: splitting resources into different resource groups within one subscription doesn't separate the bill.

Trap Using separate resource groups to split billing: invoices are per-subscription, so same-subscription resource groups land on one bill.

Azure Resource Manager (ARM) is the deployment and management service that receives every request from the portal, CLI, PowerShell, REST APIs, and SDKs through one consistent API, so you get the same results and capabilities whichever tool you use. After deployment ARM applies access control (RBAC), resource locks, and tags, and its declarative templates honor defined dependencies to deploy resources in the correct order for repeatable results.

Trap Assuming a resource created through one tool such as the portal behaves differently from one created via CLI or PowerShell, when every request goes through Azure Resource Manager for consistent results.

Every directory has a single built-in root management group (the Tenant Root Group) at the top, and all management groups and subscriptions fold up into it. A newly created subscription is placed under this root group by default (you can configure a different default target), and the root group itself can never be moved or deleted.

Each subscription and each management group can have only one parent management group at a time, which keeps governance inheritance predictable: you can move a subscription between groups but never have it in two at once. A management group tree can be up to six levels deep, not counting the root level or the subscription level.

Trap Assuming a subscription can sit under two management groups at once, when each subscription has exactly one parent management group.