Core Architecture
The physical hierarchy: geographies, regions, availability zones, and datacenters
Azure's global infrastructure is a set of nested physical units, and almost every AZ-900 placement question reduces to one: where does my data live, and where does it run? Knowing how the units nest, and what each one is for, answers it. Working from largest to smallest:
| Unit | What it is | Why it exists |
|---|---|---|
| Geography | A discrete market, usually a country or region of the world, containing two or more Azure regions. | Honors data-residency and compliance boundaries; keeps data within a legal jurisdiction. |
| Region | A set of datacenters deployed within a latency-defined perimeter and connected by a dedicated regional low-latency network. | The thing you actually pick when you deploy a resource. |
| Availability zone | One or more physically separate datacenters within a region, each with independent power, cooling, and networking. | Protects against the failure of a single datacenter. |
| Datacenter | The physical building full of servers, storage, and networking hardware that Microsoft owns and operates. | The bottom layer where your resources physically run. |
A region[1] is the unit you choose at deployment time, and that single choice determines latency to your users, which services are available, the price you pay, and where your data lives. Geographies[1] sit above regions and exist mainly to keep data inside a country or compliance boundary. The exam often phrases this as: "a customer must keep data within Germany", that is a geography/region decision, not a feature toggle.
The key relationship to memorize: a geography contains regions, a region contains availability zones, and an availability zone contains one or more datacenters. You never deploy directly to a datacenter or a geography. You deploy to a region (and optionally pin to a zone).
Availability zones: high availability inside a region
An availability zone[1] is a physically separate location inside an Azure region. Microsoft guarantees that a zone-enabled region has at least three availability zones, and each zone is made up of one or more datacenters with independent power, cooling, and networking. Because the zones are physically separated (different buildings, often on different power grids), a problem in one zone (a power loss, a flood, a network fault) does not take down the others.
The purpose of availability zones is high availability within a single region. You achieve it by spreading copies of your application or data across zones so the workload keeps running if one zone fails. The figure shows the two ways a service relates to those zones:
- Zonal services are pinned to a specific zone you choose (for example a virtual machine placed in zone 2).
- Zone-redundant services automatically replicate across the zones in the region, so the platform handles the spread for you (for example zone-redundant storage).
Not every region has availability zones, so zone-redundant deployment is only possible in regions that support them. On the exam, the trigger phrase "protect against a datacenter failure" or "keep the app running if one datacenter goes down" points to availability zones, not to region pairs (two regions used together for cross-region disaster recovery, defined fully in the next section), which solve a different, bigger problem.
Region pairs and sovereign regions: disaster recovery and data sovereignty
Region pairs
Most Azure regions are paired with a second region in the same geography, and the two regions in a region pair[2] are usually at least 300 miles (about 480 km) apart. That distance reduces the chance that a single natural disaster (earthquake, flood, large-scale power event) affects both regions at once. The figure shows the pairing: both regions sit inside one geography, separated by that distance, with replication flowing to the paired region for failover. Region pairs give you three properties the exam tests:
- Disaster recovery target: you can replicate data and workloads to the paired region so you can fail over if your primary region is lost.
- Sequential platform updates: Azure rolls out planned platform updates to only one region of a pair at a time, so an update never disrupts both regions simultaneously.
- Recovery prioritization: in a broad outage, Azure prioritizes restoring at least one region out of every pair.
The contrast to lock in: availability zones = high availability within a region (datacenter-level protection), while region pairs = disaster recovery across regions (region-level protection).
Sovereign / government regions
The regions most customers use belong to the global public Azure cloud. Azure also operates sovereign (isolated) regions that are physically and logically separated from the public cloud to meet strict government or national requirements:
| Sovereign cloud | Where | Purpose |
|---|---|---|
| Azure Government[3] | United States | Isolated cloud for US government agencies and their partners, with screened operations personnel. |
| Azure operated by 21Vianet[4] | China | Azure operated by a local partner (21Vianet) to satisfy Chinese data-residency and regulatory law. |
Whenever a scenario says data and operations must never leave a specific country or legal jurisdiction, or names a government agency with special compliance needs, the answer is a sovereign region, not a standard public region.
Resources, resource groups, subscriptions, and management groups
Azure organizes everything you create into a four-level management hierarchy. Understanding the containment and the inheritance rule is one of the most heavily tested parts of this domain.
Resources
A resource is a manageable item you create in Azure: a virtual machine, a storage account, a virtual network, a database, a web app. Resources are what you actually pay for and configure.
Resource groups
A resource group is a logical container that holds related resources. The rules to memorize:
- Every resource belongs to exactly one resource group.
- A resource can be moved to another resource group, but it cannot live in two at once.
- Deleting a resource group deletes every resource inside it, which makes resource groups a convenient way to manage and tear down a whole workload at once.
- Resources in a group can be in different regions; the resource group itself has a location only for storing its own metadata.
Group resources that share a lifecycle (deployed, updated, and deleted together) into the same resource group.
Subscriptions
A subscription is a logical container for resource groups and the boundary for billing, access, and quotas. A subscription is where charges accrue and are invoiced, and it sets limits (quotas) on how many of certain resources you can create. Organizations use multiple subscriptions to separate environments (for example dev vs production), separate billing (one bill per department), or work around quotas.
Management groups
A management group[5] sits above subscriptions. It lets you organize multiple subscriptions into a tree and apply governance (Azure Policy and RBAC (role-based access control) role assignments) to all of them at once. Management groups can contain other management groups and subscriptions, forming a hierarchy up to several levels deep, all under a single root management group for the tenant.
The inheritance rule
The single most testable concept here is downward inheritance: an Azure Policy or an RBAC role assignment applied at a higher scope is automatically inherited by everything beneath it. A policy assigned to a management group flows down to all of its subscriptions, their resource groups, and every resource. A role granted at a subscription applies to all resource groups and resources in that subscription. This is why you apply broad governance high in the hierarchy and narrow exceptions lower down. (The governance tools themselves, Azure Policy, resource locks, Azure Blueprints, are covered in the governance and compliance subtopic; here you only need the placement and inheritance behavior.)
Recognizing these questions on the exam
AZ-900 tests core architecture with definition and scenario questions. Matching the trigger phrase to the right level of the hierarchy is the whole game.
Physical-infrastructure patterns
- "Keep the application running even if one datacenter fails" → availability zones (high availability within a region).
- "Recover if an entire region is lost" or "disaster recovery" → the paired region (region pair).
- "Two regions in the same geography, at least 300 miles apart, updated one at a time" → region pair.
- "Data must stay within the country / legal jurisdiction" → choose the right geography/region (or a sovereign region for government).
- "US government agency" → Azure Government; "operations and data must stay in China" → Azure operated by 21Vianet.
- "Choose where to deploy for lowest latency to users" → pick the nearest region.
Management-hierarchy patterns
- "Apply a policy to all subscriptions at once" → assign it at a management group.
- "Container that is the billing boundary" or "where charges accrue" → subscription.
- "Logical container for resources that share a lifecycle" → resource group.
- "Delete a whole application's resources together" → delete the resource group.
- "A policy on the management group also affects the resources" → inheritance (assignments flow downward).
Distractor watch-outs
- Do not pick region pairs when the question is about a single datacenter outage. That is availability zones.
- Do not call a resource group a billing boundary. Billing is the subscription.
- Do not say a resource can belong to two resource groups. It belongs to exactly one.
- Do not assume every region has availability zones. Only zone-enabled regions do.
- Inheritance only flows downward (higher scope to lower), never upward from a resource to its subscription.
Management group vs subscription vs resource group
| Aspect | Management group | Subscription | Resource group |
|---|---|---|---|
| What it is | Container that groups subscriptions | Billing + access boundary for resources | Logical container for resources |
| Primary purpose | Apply governance across many subscriptions | Bill, set quotas, and bound access | Group resources with a shared lifecycle |
| Contains | Management groups and subscriptions | Resource groups | Resources |
| Scope level | Highest (above subscriptions) | Middle (under management groups) | Lowest (above individual resources) |
| Policy / RBAC inheritance | Inherits down to all subscriptions below | Inherits down to all resource groups below | Inherits down to all resources in it |
| Billing role | None (governance only) | The unit of billing | None (cost rolls up to subscription) |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Azure's physical footprint nests four levels
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 what you pick at deployment time
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 data-residency / compliance boundary
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.
3 questions test this
- An organization has strict data residency requirements mandating that all data must remain within a specific geographic boundary. What…
- Your company must ensure that data stored in Azure remains within the same country for compliance purposes. Which feature of Azure region…
- What characteristic ensures that data stored in an Azure region pair typically meets data residency requirements?
- A datacenter is the physical building of hardware
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.
- An enabled region has at least three availability zones
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 give high availability within one region
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 pins to one zone; zone-redundant spreads across zones
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 orAzure 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.
- Not every region has availability zones
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 is two regions in the same geography, 300+ miles apart
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.
5 questions test this
- An organization has strict data residency requirements mandating that all data must remain within a specific geographic boundary. What…
- Your company must ensure that data stored in Azure remains within the same country for compliance purposes. Which feature of Azure region…
- An organization needs to ensure that if one Azure region experiences a catastrophic failure, data is automatically replicated to another…
- What characteristic ensures that data stored in an Azure region pair typically meets data residency requirements?
- Your company needs to ensure that Azure services continue to operate if a natural disaster affects an entire Azure region. Which Azure…
- Region pairs get sequential updates and recovery priority
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.
12 questions test this
- Your organization requires that Azure planned system updates never affect both your primary and disaster recovery regions simultaneously.…
- In the unlikely event of a geography-wide outage affecting both regions in a pair, what does Azure prioritize?
- In the unlikely event of a geography-wide outage affecting both regions in a pair, what does Microsoft prioritize?
- Which benefit do Azure region pairs provide that helps minimize the impact of planned Azure platform updates?
- In the event of a geography-wide outage affecting both regions in an Azure region pair, how does Microsoft prioritize recovery efforts?
- How does Azure handle planned system updates across region pairs?
- How does Microsoft handle planned system updates for Azure region pairs?
- What is a key benefit of Azure region pairs for disaster recovery planning?
- In which scenario does Azure prioritize the recovery of one region over another?
- Your organization needs to ensure that if a geography-wide outage affects Azure, recovery of one region is prioritized. What Azure concept…
- In the unlikely event of a geography-wide outage affecting an Azure region pair, how does Microsoft prioritize recovery?
- Your company needs to ensure that Azure services continue to operate if a natural disaster affects an entire Azure region. Which Azure…
- Zones = HA within a region; region pairs = DR across regions
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 isolated for government / residency
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) andAzure 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.
8 questions test this
- Your organization must comply with Chinese regulatory requirements that mandate customer data remain within China and be operated by a…
- What distinguishes Azure operated by 21Vianet from Azure global regions?
- Your company needs to deploy Azure services in China to serve customers in that market. What should you understand about Azure availability…
- What is unique about Azure in China compared to global Azure regions?
- An organization needs to deploy Azure resources in China to comply with local data residency laws. Which statement accurately describes…
- Which organization operates Azure services in China under a physically separated cloud instance?
- Your organization is a US federal government agency that needs to deploy workloads requiring stringent security and compliance standards.…
- Your company requires a cloud environment that uses physically isolated datacenters and networks located only in the United States, with…
- Azure Government and 21Vianet are the named sovereign clouds
Azure Governmentserves 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 21Vianetruns 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.11 questions test this
- Your organization must comply with Chinese regulatory requirements that mandate customer data remain within China and be operated by a…
- What distinguishes Azure operated by 21Vianet from Azure global regions?
- Your company needs to deploy Azure services in China to serve customers in that market. What should you understand about Azure availability…
- What is unique about Azure in China compared to global Azure regions?
- Your organization operates in China and needs to use cloud services that comply with Chinese regulations, with data remaining within China.…
- Your organization requires that all workloads be deployed in Azure datacenters that are physically isolated and dedicated exclusively to US…
- An organization needs to deploy Azure resources in China to comply with local data residency laws. Which statement accurately describes…
- Which organization operates Azure services in China under a physically separated cloud instance?
- Your organization is a US federal government agency that needs to deploy workloads requiring stringent security and compliance standards.…
- Your company requires a cloud environment that uses physically isolated datacenters and networks located only in the United States, with…
- A US federal government agency requires a cloud environment that is physically separated from the public Azure cloud and operated…
- A resource lives in exactly one resource group
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.
3 questions test this
- Deleting a resource group deletes every resource in it
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.
7 questions test this
- Which best practice should you follow when organizing resources into resource groups?
- What is the primary purpose of grouping Azure resources with a shared lifecycle into the same resource group?
- What is the recommended approach for organizing Azure resources into resource groups?
- Your organization wants to deploy multiple related Azure resources that share the same lifecycle. The resources should be deployed,…
- A company is designing their Azure resource organization strategy. What should guide which resources are placed in the same resource group?
- What occurs when you delete an Azure resource group?
- Your organization needs to delete multiple Azure resources that were deployed together for a development project. What happens when you…
- Resources in one group can span regions
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 the billing and access boundary
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.
7 questions test this
- Your company has an Azure Enterprise Agreement and wants to track Azure spending separately for three business units: Marketing, Sales, and…
- Which statement accurately describes how Azure generates billing reports and invoices by default?
- What defines the billing boundary for Azure services where invoices are generated and payments are managed?
- For which resource does Azure generate separate billing reports and invoices by default?
- What does an Azure subscription provide for resource management and cost tracking?
- Your company wants to track Azure costs separately for the development and production environments. What should you recommend to create…
- Your organization has multiple departments that need separate invoices for their Azure resource usage. What should you create to ensure…
- A management group groups subscriptions for governance
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.
6 questions test this
- What is the primary purpose of Azure management groups?
- Your organization has many Azure subscriptions and needs to efficiently manage access, policies, and compliance across all of them. What…
- A company needs to apply consistent Azure policies across all subscriptions in multiple business units. Which hierarchy component should…
- Your organization has multiple subscriptions that require the same Azure Policy definitions. What should you use to apply the policies to…
- Your organization has multiple Azure subscriptions across different departments. You need to apply consistent security policies across all…
- Your organization needs to apply the same Azure Policy to multiple subscriptions across different departments. What should you use to apply…
- The hierarchy: management group > subscription > resource group > resource
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.
- Policy and RBAC inherit downward, never upward
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.
9 questions test this
- What is the primary purpose of Azure management groups?
- You need to ensure that all current and future subscriptions in your Microsoft Entra tenant inherit specific governance settings. At what…
- A subscription that is moved to a new management group inherits which of the following from the parent management group?
- Your organization has many Azure subscriptions and needs to efficiently manage access, policies, and compliance across all of them. What…
- A company needs to apply consistent Azure policies across all subscriptions in multiple business units. Which hierarchy component should…
- What happens when you assign an Azure Policy to a management group?
- Your organization has multiple subscriptions that require the same Azure Policy definitions. What should you use to apply the policies to…
- Your organization has multiple Azure subscriptions across different departments. You need to apply consistent security policies across all…
- Your organization needs to apply the same Azure Policy to multiple subscriptions across different departments. What should you use to apply…
- Apply broad governance high, narrow exceptions low
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.
- A resource group is not a billing boundary
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.
3 questions test this
- Your organization has multiple departments that need to track their Azure costs separately. Each department requires its own billing report…
- Your organization has multiple departments that require separate invoices for their Azure resources. What should you use to ensure each…
- What provides a billing boundary for Azure resources and generates separate billing reports and invoices by default?
- Azure Resource Manager is the single management control plane
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.
5 questions test this
- What is a key benefit of Azure Resource Manager handling all Azure management requests through the same API?
- What benefit does Azure Resource Manager provide by handling all requests through the same API?
- Which management features can you use through Azure Resource Manager after deploying resources? Select the answer that includes three…
- Which feature does Azure Resource Manager provide to help secure and organize resources after deployment?
- Your company wants to deploy and manage Azure resources using declarative templates rather than scripts. Which benefit does Azure Resource…
- New subscriptions land under the root management group
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.
5 questions test this
- Your organization has a Microsoft Entra tenant with multiple Azure subscriptions. Where are all new subscriptions placed by default when…
- You need to ensure that all current and future subscriptions in your Microsoft Entra tenant inherit specific governance settings. At what…
- Which statement about the root management group in Azure is correct?
- Where are all new Azure subscriptions placed by default when they are created within a tenant?
- When a new Azure subscription is created, where is it placed by default in the management group hierarchy?
- A subscription or management group has exactly one parent
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.
5 questions test this
- What is the maximum number of levels of depth that a management group tree can support, not including the tenant root level or the…
- Which statement correctly describes the relationship between Azure subscriptions and management groups?
- A subscription can be moved between management groups. How many parent management groups can a subscription belong to at any time?
- A company wants to apply a consistent security policy across all their Azure subscriptions without having to assign the policy to each…
- In Azure, how many parent management groups can a subscription or management group have?
Also tested in
References
- https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview
- https://learn.microsoft.com/en-us/azure/reliability/regions-paired
- https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-welcome
- https://learn.microsoft.com/en-us/azure/china/overview-operations
- https://learn.microsoft.com/en-us/azure/governance/management-groups/overview