An original fictional placement review shows why region selection, zone labels and administrative grouping are different evidence. Trace a cross-subscription uncertainty, then test a supplied mapping and a capability-versus-deployment claim.
Direct answer: a placement label is only part of the evidence
Use a region to reason about geographic placement and use availability-zone evidence to reason about a more local infrastructure failure boundary. Then inspect the service and resource configuration that actually uses those locations. A region supporting zones does not establish that a particular resource uses several of them. A resource-group or subscription name is administrative evidence rather than a physical placement record. These distinctions matter before discussing availability, latency or residency; a confident diagram can otherwise hide the very assumption the review needs to test.
This independent guide follows a fictional film-preservation exchange, not the lesson’s administrative example or the formal placement task. The exchange has two Azure subscriptions in its approved region R. Each project team writes “zone 1” beside a service in its own subscription. Their review question is whether those labels establish physical separation. Region R and the mapping labels in the examples are invented teaching names; no current Azure region count, service SLA or real deployment is asserted.
Separate geography, administration and zone naming
An Azure region provides a geographic grouping of infrastructure. Availability zones are separated groups of datacenters within a region that supports them. Their independent infrastructure can support resilience to a zone failure, but the actual service and resource must use an appropriate supported arrangement. Some services manage a zone-redundant deployment; others require configuration or use a zonal resource. The feature of the region and the topology of the resource are therefore two separate observations.
Subscriptions and resource groups organize management. A resource group stores metadata in its specified location, while its contained resources can have their own deployment locations. That means neither common membership nor a group’s metadata Location field proves where each application resource runs. A management change also does not by itself move the workload to a new region. Keep an administrative inventory and a placement inventory as separate records, then connect them with the actual resource identity when investigating a claim.
Work the cross-subscription uncertainty
The exchange’s two “zone 1” labels need another distinction. Azure maps physical zones to logical zone numbers for a subscription, and different subscriptions can have a different logical-to-physical mapping. Thus matching logical numbers across subscriptions do not by themselves prove a common physical zone; different numbers across subscriptions do not by themselves prove separation either. The review must obtain the applicable mapping or other service-specific placement evidence. It should record this as unknown rather than silently treating the repeated numeral as a physical identifier.
Work the question in order. First, the approved-region condition places both described components in R, subject to verifying their actual resource locations. Second, the logical labels identify each team’s subscription-level view. Third, the proposed physical-separation conclusion needs a mapping that the current description does not supply. The justified result is an evidence gap, not a claim that the resources certainly share a zone or certainly occupy different ones. This is a useful conclusion: it names exactly what the next check must resolve instead of offering an unsupported availability guarantee.
Change one fact and re-evaluate
Suppose a later fictional mapping table states that subscription A’s logical zone 1 maps to physical site B, and subscription T’s logical zone 3 also maps to physical site B. Now the numeric labels differ but the supplied physical boundary is the same. The new evidence changes the conclusion. Conversely, if evidence placed the resources in distinct physical zones and the selected service/application actually supported the intended operation across them, that would address the stated local failure boundary. It still would not establish recovery from every regional disruption or every application dependency failure.
Region pairs, sovereign-region arrangements and interregional recovery require their own current facts and workload requirements. A pair label is not a substitute for knowing which service replicates which data, what configuration is enabled, or how failover is tested. Similarly, a geographic policy supplied by a fictional case can constrain placement, but this lesson is not a legal compliance determination. Avoid adding a universal outage promise merely because an official service has a service-specific availability commitment.
Use the diagram as a question path
The original diagram deliberately leaves the physical mapping as a question to verify. Read its three rows separately: geographic requirement, logical labels in administrative contexts, and the physical/service evidence needed for the claim. The arrows are a study aid rather than copied Microsoft architecture art. No arrow creates a deployment or configures replication. This makes the diagram useful when a teammate proposes an inference from a name: point to the missing row and ask for the actual evidence.
Try the two reinforcement checks below before reading their answers; prior example exposure applies. A good response identifies what the supplied mapping or configuration proves and what it leaves unresolved. Then use the linked lesson for the basic region/management vocabulary and independent practice for another constrained placement decision. This guide is selected conceptual preparation, not a complete Azure reliability design, full AZ-900 syllabus, production procedure or calibrated assessment. Qualified educator review and learner trial remain separate pending work.
Apply the guide
A fictional mapping lists subscription U logical zone 2 → physical C and subscription V logical zone 1 → physical C. Do the different logical numbers establish physical-zone separation for these two placements?Reveal explanation
No. The supplied mapping puts both at physical C. Different logical numbers across subscriptions are not proof of physical separation; use the actual mapping and relevant service configuration.
A region supports zones, but a project lists only one selected zonal resource. Does the region capability alone establish that this resource is zone-redundant? What must be checked?Reveal explanation
No. Check the resource’s actual service-specific deployment/configuration and which zones it uses. Region capability does not by itself show that one listed zonal resource is distributed across several zones.
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Current Microsoft region, zone and Resource Manager references ground factual distinctions. All review cases, mapping labels, checks, prose and diagram are original; no official question or diagram is reproduced.
Original independent placement-evidence critique, not duplicated course body or video companion.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
What are Azure regions?What are availability zones?What is Azure Resource Manager?