# Azure Region Selection for Compliance > Chapter 127 of the Courseiva AZ-900 curriculum — https://courseiva.com/learn/az-900/azure-regions-governance **Official objective:** 3.2 — Azure Management Governance ## Introduction This chapter covers how Azure region selection relates to compliance and data-residency needs, at the level AZ-900 expects. AZ-900 tests this under objective 3.2, alongside the broader governance concepts covered in nearby chapters. ## A Country's Border, Not a Single Building If a law requires a company to keep certain records "in the country," that generally means anywhere within the country's borders — not literally the exact building where the paperwork was first filed. Azure's data-residency boundary works similarly: it's generally tied to the broader geography a region belongs to, not necessarily the single, exact region selected, and the specific behavior depends on which service you're using. ## Core explanation ### Regions and geographies, and why the distinction matters for residency An Azure region is a specific area with a set of datacenters. A geography (often a country or defined area) is the broader boundary that can contain multiple regions. For data-residency purposes, the geography is generally the more relevant boundary — some services keep data within the exact selected region, while others may involve a paired region within the same geography, depending on the specific service and how it's configured. Because this varies by service, the exam-safe idea is: **Azure regions sit within geographies that provide data-residency boundaries, and the exact residency behavior depends on the specific service and its configuration** — not a blanket guarantee that data never leaves the one region you picked. ### Sovereign and specialized regions Azure also offers specialized regions for certain government or regulatory needs (for example, regions serving U.S. government customers), which come with their own additional compliance certifications and operate somewhat separately from Azure's standard commercial regions. ### Azure Policy for enforcing region choices Organizations with specific residency requirements can use Azure Policy (covered in its own chapter) to restrict which regions resources can be deployed to, helping enforce a chosen boundary consistently rather than relying on individuals remembering the rule. ### Compliance is broader than region selection alone Region selection is one part of meeting compliance requirements — it doesn't substitute for broader compliance work like reviewing a service's specific certifications, encryption settings, and contractual commitments. For AZ-900 purposes, the takeaway is simply: when data-residency or compliance requirements exist, choose an appropriate Azure geography/region for them, and verify the specific service's documented behavior rather than assuming a single rule applies universally across all Azure services. ## Real-world context An organization with a regulatory requirement to keep certain data within a specific country selects a region within that country's geography, and uses Azure Policy to prevent resources from accidentally being created elsewhere. A separate organization assumes, incorrectly, that simply picking one region guarantees its data will never touch any other region under any circumstance — and later discovers that a specific service they're using has its own documented replication behavior that needed separate review, illustrating why checking the specific service matters rather than relying on a single blanket assumption. ## Exam focus Objective 3.2 expects a conceptual understanding that geographies provide the broader data-residency boundary, that residency behavior can vary by service, and that Azure Policy can help enforce region choices — not memorization of specific regulations' legal text. A common wrong answer is treating region selection as an absolute, one-size-fits-all guarantee ("my data can never leave the exact region I selected") — the more accurate, exam-safe understanding is that geographies provide the residency boundary and specific behavior depends on the service. Another common trap is treating any single regulation (like GDPR) as having one simple, universal rule — real regulatory requirements are more nuanced than a single sentence can capture, and AZ-900 only expects the general concept: choose an appropriate geography/region when residency requirements exist. Stable terms: **geography**, **region**, **data residency**. Memory trick: think geography first, region second, and always check the specific service's documented behavior rather than assuming one rule covers everything. ## Step by step 1. **Identify whether a residency requirement applies** — Determine whether the workload has a legal or regulatory requirement about where its data can be located. 2. **Choose an appropriate geography and region** — Select a region within a geography that satisfies the requirement, checking that needed services are available there. 3. **Check the specific service's residency behavior** — Because residency behavior varies by service, review that service's own documentation rather than assuming a single universal rule applies. 4. **Enforce the choice with Azure Policy if needed** — For stricter requirements, Azure Policy can restrict which regions resources can be deployed to, enforcing the choice consistently. ## Comparisons ### Region vs Geography **Region:** - A specific area with data centers - Where a resource is actually deployed **Geography:** - The broader boundary containing one or more regions - The more relevant boundary for data-residency purposes ## Common misconceptions - **Misconception:** Data deployed in a specific region can never, under any circumstance, exist anywhere else. **Reality:** Residency behavior depends on the specific service and its configuration — geographies provide the broader boundary, and some services involve replication within that geography. Check the specific service's documentation rather than assuming a single universal rule. - **Misconception:** GDPR simply means EU citizens' personal data must always stay inside the EEA. **Reality:** GDPR includes rules governing transfers of personal data outside the EEA, including mechanisms that can make such transfers lawful — it's more nuanced than a single absolute rule. For AZ-900 purposes, the relevant takeaway is simply choosing an appropriate geography/region when residency or compliance requirements exist. - **Misconception:** Region selection alone satisfies all compliance requirements. **Reality:** Region selection is one part of a broader compliance picture, which also includes a service's specific certifications, encryption, and contractual commitments. ## Key takeaways - Azure regions sit within geographies, and geographies generally provide the more relevant data-residency boundary. - Exact residency behavior varies by service — check that service's documentation rather than assuming one universal rule. - Azure Policy can help enforce region choices consistently across an organization. - For AZ-900 purposes, the key idea is simply: choose an appropriate geography/region when data-residency or compliance requirements exist, and verify specifics per service. ## FAQ **Does choosing a specific Azure region guarantee my data never leaves it?** Not as an absolute guarantee — residency behavior depends on the specific service and its configuration. Geographies (the broader boundary containing the region) are generally the more relevant boundary for residency purposes. Always check the specific service's documented behavior. **Does GDPR require EU citizens' data to always stay within the EEA?** It's more nuanced than that — GDPR includes rules governing transfers of personal data outside the EEA, including mechanisms that can make such transfers lawful. For AZ-900, the relevant idea is simply choosing an appropriate geography/region when compliance requirements exist, not memorizing GDPR's full legal detail. **Is picking the right region enough to be compliant?** No — region selection is one part of a broader compliance picture, which also includes a service's specific certifications, encryption settings, and contractual commitments, not something region choice alone fully satisfies. --- Interactive version with quiz and diagrams: https://courseiva.com/learn/az-900/azure-regions-governance