Start with two different maps
AZ-900 questions often place several Azure terms together even though they solve different problems. Use a physical deployment map for datacenters, regions and availability zones. Use a management-scope map for management groups, subscriptions, resource groups and resources.
Deployment boundary
Where a workload runs and which infrastructure failure it can tolerate.
Management boundary
How resources are organized, billed, governed and authorized through Azure Resource Manager.
Exam rule
Do not choose a resource group to solve datacenter resilience or an availability zone to organize billing.
Physical deployment boundaries: geography, region and zone
An Azure region is a geographic deployment area containing datacenters. You select a region when deploying many Azure resources because location affects service availability, latency, data residency and recovery design.
An availability zone is a separated group of one or more datacenters within a supported region. Each zone has independent power, cooling and networking. A workload configured across zones can continue operating when one zone fails, subject to the chosen service and architecture.
- Single-region, multi-zone: protects against supported failures inside the region while keeping components within the regional boundary.
- Multi-region: addresses regional failure or global-distribution requirements, but requires a service-specific replication, routing and recovery design.
- Region pair: a relationship used by some Azure services for geo-replication or recovery behavior. Not every region is paired, and the relationship is not automatic disaster recovery.
- Service support: not every service, SKU or region supports the same zonal or multi-region configuration. Verify the current service documentation before designing production resilience.
AZ-900 failure-boundary clue
Datacenter-level failure inside one region: consider availability zones. Complete regional disruption: consider an appropriate multi-region design. Lower user latency: choose suitable regions and delivery services based on the workload.
Azure management hierarchy: scope, not geography
Azure Resource Manager provides four common management scopes. A setting applied at a higher scope can affect lower scopes through inheritance where that feature supports it.
- Management group: organizes multiple subscriptions so governance and access can be applied consistently above the subscription level.
- Subscription: a management and billing boundary that contains resource groups and resources. Access, quotas and policies can be scoped here.
- Resource group: a container used to manage related resources for a solution. Resources normally share a lifecycle when grouping them together is operationally useful.
- Resource: an individual manageable Azure item such as a virtual machine, virtual network, storage account or database.
A resource group has a location because Azure stores its metadata somewhere, but that does not force all contained resources into that location. Resources in one resource group can use different regions when the design requires it and the services support it.
Scope hierarchy
Management group → Subscription → Resource group → Resource. Choose the narrowest practical scope for an assignment, and remember that inherited policy or role assignments may affect child scopes.
Compare the concepts by purpose
Worked scenario: resilient customer portal with clear governance
A company wants an Azure customer portal to tolerate a datacenter failure, keep production separate from development and apply mandatory tags across production.
- Select an Azure region that supports the required services and availability-zone configuration.
- Deploy supported application components across multiple availability zones to reduce the impact of a zonal failure.
- Place production resources in purpose-designed resource groups based on lifecycle and operational ownership; do not use the group itself as a resilience mechanism.
- Use separate subscriptions when the organization requires stronger billing, quota, policy or access boundaries between production and development.
- Place subscriptions under appropriate management groups so shared governance can be assigned above them.
- Assign Azure Policy for required tags at the correct management-group, subscription or resource-group scope.
- Design and test a separate multi-region recovery approach if a complete regional outage is within the business requirement.
The design combines both maps: zones and regions address failure boundaries; management groups, subscriptions and resource groups address organization and governance.
Common AZ-900 mistakes
- Calling an availability zone a separate Azure region.
- Assuming every Azure region and service supports availability zones.
- Assuming deployment in a paired region happens automatically.
- Using resource groups as a billing or physical-isolation boundary.
- Assuming resources in a resource group must share the resource group's metadata location.
- Confusing a subscription with a Microsoft Entra tenant.
- Forgetting that assignments at higher management scopes can affect child scopes.
- Selecting a term because it sounds similar instead of identifying whether the question concerns location, failure, billing, lifecycle or governance.
AZ-900 practice checks with explanations
A workload must remain available if one datacenter grouping in its Azure region fails. What should the design evaluate?
Best answer: availability-zone support and a multi-zone deployment for each required service. A resource group does not provide infrastructure redundancy.
The company wants one policy to apply to several Azure subscriptions. Which scope helps?
Best answer: a management group above those subscriptions, assuming the hierarchy and policy scope match the governance requirement.
Can a storage account and virtual network in the same resource group use different Azure regions?
Best answer: yes, where the services and design permit it. The resource group organizes management; its metadata location does not force every resource into the same region.
Resources are placed in two paired regions. Is disaster recovery complete?
Best answer: no. The application must configure suitable replication, routing, failover and recovery procedures, then test them.
Frequently asked questions
What is the difference between an Azure region and an availability zone?
An Azure region is a geographic deployment area containing datacenters. An availability zone is a separated group of one or more datacenters inside a supported region, with independent power, cooling and networking.
Is an Azure resource group a physical location?
No. A resource group is an Azure Resource Manager container for related resources. Its location stores the resource-group metadata; resources inside it can be deployed in different Azure regions.
Do availability zones protect against a complete regional outage?
No. Zones improve resilience to failures within one region. A complete regional outage requires a multi-region recovery or availability design appropriate to the service and business requirement.
Does choosing a paired Azure region automatically create disaster recovery?
No. Microsoft states that placing resources in paired regions does not automatically provide high availability, disaster recovery or failover. The workload must use and test suitable replication and recovery capabilities.
What is the Azure management hierarchy?
The four common Azure management scopes are management group, subscription, resource group and resource. Settings such as policy and role assignments can be applied at a scope and inherited by lower scopes where supported.
Official Microsoft references
- Current AZ-900 study guide
- Azure availability zones
- Paired and nonpaired Azure regions
- Azure Resource Manager and management scope
Confirm current service and region support before making production decisions. ITCertPath uses original learning explanations and does not reproduce confidential Microsoft exam questions.